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1.0. Introduction 

This document describes the DO processor, memory, and input-output system. The DO is a 
microprogrammed machine which is customized to some extent to provide efficient emulation 
of the Mesa instruction set, and to provide high memory bandwidth for demanding input- 
output devices. The DO has a multitasking control structure which multiplexes the processor 
among sixteen fixed priority tasks at the microcode level. The lowest priority task is used to 
implement the emulator for the Mesa instruction set. 

The principal performance parameters of the DO are: 

Clock Rate: TBDns. Microinstructions are pipelined, and require four cycles for execution. A new 
microinstruction is started every two clock times. 

Data Path Width: 16 bits 

Arithmetic: 2's complement 

Control Store: 4K words of 36 bits 

Main Storage: 22-bit virtual address space provided. 64K-768K words of real memory may be 
connected (1M word with 64K RAM chips). Main storage is error corrected over a 64-bit quadword. 

1.1 Notation 

Throughout this document, a number of conventions are used, which are described in this 
section. 

1.1.1 Numbers 

Numeric quantities are expressed in decimal unless otherwise specified. The suffix b is used 
to indicate octal. 

* is used to indicate multiplication, ** is used to indicate exponentiation: 

5d3 = 5000 = 5*10**3, 3b5 = 300000b = 3*8**5 

For large multiples of a power of 2, K is used to designate 2**10, and M is used to 
designate 2**20: 

32K = 32*2**10 = 2**15 = 32768, 
1M = 1*2**20 = 2**20 = 1048576 



1.1.2 Special Characters 

<x> means "contents of x M . 
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Square brackets [] are used to indicate indexing or to delimit the arguments of a function: 

x(3J * <x+3> means the contents of location x+3, i.e. the 
third element of the vector x 

hf{2l means the value returned by the function hf with 
argument 2. 

Double commas are used to indicate the concatenation of two fields. If x is a 3-bit field and 
y is a 5-bit field, then x„y is an eight-bit field with x in its high order bits. 

1.1.3 Terms 

A word is a sixteen bit quantity. Bit is the most significant bit, bit 15 is the least significant 
bit. When diagrammed, bit is on the left. 

A doubleword is a thirty-two bit quantity, with bits numbered from to 31. In main storage 
the least significant bits (16-31) of a doubleword are stored in location n, the most significant 
bits (0-15) are stored in location n + 1. 

A byte is an eight bit quantity. Bit is the most significant bit, bit 7 is the least significant 
bit. When diagrammed, bit is on the left. 

A field is a contiguous group of bits within a word or larger field. The bits are numbered 
from the left. For example, the field consisting of the least significant byte of x is indicated 
with x[8:15]. 

1.1.4 Register Naming Conventions 

Registers in the DO (usually) have names that are related to the function performed by the 
register. This section discusses the conventions used for register names in this document 
and in the logic diagrams for the machine. Note that these conventions are usually, but not 
universally, observed. In cases where clarity is increased by deviating from these 
conventions, we have deviated. 

In the simplest case, a register holds a single n-bit value. The bits of the register are simply 
numbered, for example, Hi [0:1 5]. In the logic drawings, the field notation is not used, since 
these drawings depict individual signals. Instead, the register name and the bit number are 
"dotted" to form a signal name, e.g., H1.00, or Stkp.7. 

In some cases, a single register will contain subfields which are explicitly named For 
example, the field ALUF[0:3] is a subfield of the microinstruction register MIR. In the logic 
drawings, the individual bits of a register are given tne subfield name (e.g., ALUF 0) since 
this is more descriptive of the signal's function than giving the bit number in the' larger 
register. Often, a group of signals which have a similar purpose or similar timing are treated 
as a reg.ster with a number of single-bit subfields. The Result register, which consists of the 
signals Overflow, ALUOut = 0, ALUCarry, and ALIKO, is an example. On the logic drawings 
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the name "Result[i] M never appears. The Result register is a logical entity provided solely for 
clarity of description. 

In a number of cases, registers in the DO hold complemented values, or the values are 
complemented as the register is read from one part of the processor to another. In this 
document, register names are used as if the register contained high-true values, but the 
tables which summarize the registers are explicit about complementation, as are the logic 
drawings. For example, we speak of "the H2 register" , or "H2[0:15]" frequently. In fact, H2 
holds complemented data, but the descriptions of the ALU functions have been chosen to 
provide the necessary inversion. In the logic drawings, the bits of this register are named 
H2.00' through H2.15' (i.e., low-true names). 



10 Major Subsections 

This section describes the major subsections of the DO. Later sections will provide 
increased detail. The principal registers and data paths of the processor are shown in figure 
2.1. Figure 2.2 shows the control section, figure 2.3 shows the principal paths associated 
with the memory, and figure 2.4 shows miscellaneous control logic. These figures 
correspond to the partitioning of the logic onto printed wiring boards. Figure 2.5 
summarizes the microinstruction format of the DO. Two formats are used, one for memory 
references, one for other instructions. 

2.1 Registers and Data Paths 

The arithmetic section of the DO is organized around a 16-bit Arithmetic/Logic Unit (ALU). 
The ALU is fed by two registers H1 and H2 which are inaccessible to the programmer. 

The H1 register is loaded at t1 from the R bus, which is usually fed from the R memory, but 
may also be driven by a number of other registers in the processor. The R bus is driven by 
tri-state drivers, and goes to all processor cards. 

The H2 register is loaded at t1 from the T RAM or from the F1 and F2 fields of the 
microinstruction. F1 and F2 are interpreted as an eight bit constant in this case. The 
constant may be placed in either byte of a word; the other byte is zeroed. 
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Figure 2.1 Processor Data Paths 
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2.2 Control 

The DO provides a task switching mechanism which multiplexes the processor among sixteen 
fixed priority microcoded tasks. The lowest priority task is used to implement an emulator 
for the Mesa instruction set. The highest priority task (task 15) is used for error handling. 
Task 14 is permanently assigned to an array of interval timers, and the remaining thirteen 
tasks are used to implement the microcoded portions of input-output device controllers. 

A hardware device controller requests service from the processor by placing an encoded 
version of its associated task's number on three wakeup request lines. If this task number is 
greater than the task which is running on the processor, and if there is no higher priority 
device requesting a wakeup, the task associated with the requesting device will acquire the 
processor when the running task next executes a RETURN instruction. The T register and 
the microprogram location counter (TPC) are task specific, which makes task switching 
overhead small. Once a task has acquired the processor, it will keep control until it 
executes a RETURN instruction and its wakeup request line is no longer active or there is a 
higher priority wakeup request. Microprograms should do RETURNS every few cycles 
{maximum TBD} to avoid long latencies for higher priority tasks. 

The lowest priority task (task 0) is always requesting a wakeup. This task contains the 
microcode for the Mesa emulator. Task will run if there is no higher priority input-output 
activity. The highest priority task (task 15) is used for error handling functions, and is given 
control by a special mechanism when an error occurs. 

The processor provides the facility for each task to modify the saved program counter of 
other tasks, and to cause another task to get control of the processor. 

The processor does not have an incrementing program counter. Instead, - .each 
microinstruction specifies the address of its successor using one or more fields in the 
microinstruction. There are a number of branch formats, which use a varying amount of the 
microinstruction for their specification depending primarily on their degree of locality. The 
processor provides a single level of subroutine linkage for each task. When a subroutine 
call is executed, the return link is stored in the TPC RAM location associated with the 
current task (TPC(current]). When a RETURN is executed, the next microinstruction is 
accessed from the location in the control store pointed to by the TPC ceil associated with 
the hightest priority requesting task (TPC[HTASK]). This is the reason that RETURNS cause 
task switches. 
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Figure 2.2 Processor Control 
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2.3 Memory and Input-Output 

The memory system of the DO supports a 2**22 word virtual address space and a 768K word 
real address space. When 64K RAM chips become available, it will be possible to attach up 
to 1M words of storage. All memory references are made by the processor, including 
references made on behalf of IO controllers. 

A special microinstruction format is used to initiate memory references. The instruction 
specifies a pair of R registers to be used as a base register, the type of reference, and the 
source or destination of the data. Once the memory has been started, references proceed in 
parallel with processor activity. 

The memory is pipelined, allowing two memory references to be in progress at once. 

From the standpoint of the IO controllers, memory references and input-output operations 
are essentially identical, since they use the same busses for data and device address 
transfers. There are separate busses for input and output, and these activities may proceed 
in parallel if circumstances permit. The processor has an OUTPUT operation which transfers 
a single word from an R register to the device register addressed by H2(8:15], and an INPUT 
operation which reads the IO device register addressed by H2 into an R register. 
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2.4 Timing 



This section discusses the conventions used to describe the timing of the DO, and gives an 
overview of the timing of the basic data paths. 

A cycle is the basic unit of time in the machine. Cycles are TBD ns. in length. The clock 
associated with a particular cycle occurs at the end of the cycle. 

An instruction time is two cycles, since even though most instructions really require four 
cycles to finish all their activity, a new instruction may be started every two cycles. 

Time within an instruction is counted from the time the instruction is loaded into the MIR 
(Microinstruction Register). This is called to. 

The period between to and t1 is referred to as cycleO, that between tl and t2 as eyelet, etc. 

The timing of normal instruction execution is shown in figure 2.6. During cycleO, the data 
sources used in the instruction (usually the R and/or T registers) are accessed. This data is 
loaded into the H1 and H2 registers at t1 . During cyclel and cycie2, the data is operated on 
by the ALU, and the result is loaded into the H3P register at t3. During cycle3, data from 
H3P is written into R and T if the instruction specifies loading of these registers. 

Calculation of the next instruction's address and the control store fetch for the next 
instruction is done during cycleO and cyclel in parallel with execution of an instruction. 
Note that t2 for one instruction is usually coincident with tO for the next instruction, t3 is 
coincident with t1, and t4 is coincident with t2. 

During execution of a conditional branch instruction, the control store access is begun at to 
using an even address, assuming that the test condition is false and that the branch will not 
be taken. The branch conditions become stable slightly after tl , and if the condition is true, 
an extra cycle is inserted to allow the control store sufficient time to access the odd location. 
This is not visible to most of the processor logic, since the CPU control store simply 
withholds one Clock. (Note: EdgeClockFeed is withheld, RamCiockFeed is not. This means that RAM writes 
during cyclel may be done twice, but this is harmless.) 

Under certain circumstances, an instruction may be Aborted, as described in section 4.5. 
• Aborted instructions are repeated automatically unless a fault occurs (section 4.6). 

Microinstructions may also be suspended. Suspension occurs when the memory controller 
needs to access the R memory. The processor is suspended for one cycle for each word 
transferred between the memory and R. Suspension does not withold any clocks, so it is 
invisible to I/O devices (except for the logic that generates wakeup requests). Processor 
activities are simply delayed when a cycle is suspended. 

Most of the discrete registers in the processor are loaded at t2. The data used to load 
these registers is usually taken from the ALUA bus, which becomes stable at ~t1 + 45ns. 
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The only registers which are written later than t2 are R, T, and the Result register. 
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3.0 Arithmetic Section 

3.1 Register Summary 

Table 3.1 is a summary of all registers and memories which are accessible to the 
programmer. 

3.2 R Memory 

The R Memory is a 256 word by 16 bit memory used for high speed storage in the 
processor. The RSEL and RMOD fields of the microinstruction select an R register to be 
read or written during an instruction. In addition, a number of discrete registers in the 
processor are selected for reading (but not loading) by RSEL and RMOD. Information read 
from R is latched in the H1 register (inaccessible to the programmer) at t1, from which it is 
passed through the cycler/masker to one of the ALU inputs. 

Since a microinstruction requires four cycles for execution, with R writes occupying the last 
cycle, and since instructions may be started every two cycles, an R location may be written 
by one instruction and read by the next before the write is actually done. The processor 
contains logic to bypass the R memory in this case so that the write appears to a 
microprogram to be done during the instruction in which it is specified. 

A microinstruction generates a single R address. The selected R register may be used as a 
data source under control of other fields of the instruction, and is written from the output of 
the ALU if LR = 1. 

3.2.1 R Address Formation 

The R address is an 8-bit quantity. If RMOD « 0, the R address is formed by concatenating 
the two most significant bits of the current task number and the (6 bit) RSEL field. In 
addition RSEL[0:1] is replaced by the two least significant bits of the current task number if 
RSEL[0:1] = 0. The effect of this is to divide the 256 word R memory into four 64-word 
blocks. Four tasks share a block. Within the block and the four tasks which can directly 
address it, task can address the entire block, tasks 1 , 2, and 3 can only address locations 
16-63. The idea here is that (1) the emulator task needs to be able to directly address an 
entire 64 word block, and (2) up to four IO controllers of the same type can share microcode 
if their task numbers are initialized to 0,1,2,3 mod 4. The microcode is written as if the 
device occupied task of the block of four tasks, and the R addresses (and IO device 
addresses) will be modified according to which of the four tasks is in control. 

If RM0D = 1, the R address is modified as follows: 

If RSEL[4:5]=0, 1. or 2, RSEL[4:5] is replaced by the registers PCF[1:2], SBX[0:1], or DBX[0:1] 
respectively. This allows these registers to index a 4-word area in R. The PCF register contains the 
low order three bits of the Mesa byte program counter. SBX and DBX contain the current source and 
destination word numbers for two quadword buffers used by the BitBLT operation. 

If RSEL[4:5] = 3, and RSEL[0:1] = 3, the stackpointer (Stkp) provides the 8-bit R address. In this case, 
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RS£L(2:3] indicates the amount by which the stackpointer is to be incremented or decremented. 

if RSEL{4:5]s3, and RSEL(0:1]=0, 1, or 2, the R memory is disabled for reading, and other R bus 
sources are enabled. A number of discrete registers in the processor are read in this way (see Table 
3.1). Registers which are less than sixteen bits in length are packed into words as tightly as possible 
without crossing word boundaries. The idea here is that these registers may be accessed using short 
tfe/d descriptors (described later). The function RegShift (F2*0) is provided to increase the number of 
registers which may be selected in this way. 
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Table 3.1 








Register 


Size 


Loaded 


Load 


Load 


Read 


Read 


Section 




(bits) 


From 


Cont roi 


Time 


To 


Control 




R 


256x16 


H3P 


LRxi 


Cycle3 


H1 


RMOD=0 


3.2 


T 


16x16 


H3P 


LT = 1 


Cycle3 


H2 


BSEL = 2,3 


3.3 


Map 


16Kx16 


R 


XMap 


- 


R 


XMap 


5.4 


SALUF: 
















MA' 


1 


H2 


[08] 


F2 = 11b 


t2 


R[08] {1} 


SR = 7 


3.5.1,3.6.3.2 


MB 


1 


H2[09] 


F2 = 11b 


t2 


R[09] {1} 


SR = 7 


3.5.1,3.6.3.2 


SALUF(0:5] 


6 


H2 


[10:15] 


F2 = 11b 


t2 


R[10:15]{1} 


SR = 7 


3.5.1 


Resutt: 
















ALU<0 


1 


ALUOUT[00] 


GB = 11b 


t3 


R[00]{1} 


SR = 7 


3.5.2 


ALUCarry 


1 


ALUOUTfOf 


GB = 11b 


t3 


R[01]{1} 
R[02J{1} 
Rf03]{1} 


SR = 7 


3.5.2 


ALU#0 


1 


ALUOUT[01 


GB = 11b 


t3 


SR = 7 


3.5.2 


NoOverflow 


1 


ALUOUT[03 


GBs11b 


t3 


SR = 7 


3.5.2 


Note: Result is also loaded at t3 of all instructions that do 


not contain 


F2 = 2 (Freez 


Stkp 


8 


ALUA[8:15] 


F2*1 


t2 


R 


[8:15]{1} 


SR = 3 


3.2.2 


SStkp 


8 


Stkp[0:7] 


{6} 


t2 


R 


0:7] 


SR = 3 


3.2.2 


APCTask 


4 


ALUA(0:3] 


GB = 10b 


t2 


R 


0:3] 


SR = 43b 


4.3 


APC 


12 


ALUA[4:15] 


GB = 10b 


t2 


R 


4:15] 


SR = 43b 


4.3 


InCTsk 


4 


APCTask[0:: 


«{3} 


t2 


R 


0:3] 


SR = 47b 


4.6 


CIA 


12 


C-SAddress 


{3} 


t2 


R 


;4:15]{1} 


SR = 47b 


4.1 


CSData 


16 


C-S 


GB = 14-17b,H2 t2 


R 


0:15] 


SR = 53b 


4.9 


Page 


4 


F2[0:3] 


F1=5 


t2 


R 


[0:3] 


SR = 57b 


4.1 


Parity Errors: 
















StackOvf 


1 


{3} 
{3} 


W 


t2 


R[04] 


SR = 57b 


3.7 


CS-ParErr 


1 


t2 


R[05] 


SR = 57b 


3.7 


R-ParErr 


1 


{3} 


W 


t2 


R[06] 


SR*57b 


3.7 


MemErr 


1 


{3} 


W 


t2 


R[07] 


SR = 57b 


3.7 


BootReason: 
















RFB(0] 


1 


TesterBoot 


{5} 


boot 


R[10] 


SR = 57b 


4.10 


RFB[1] 


1 


PanelBoot 


ft 
{5} 


boot 


R[11] 


SR = 57b 


4.10 


RFB[2] 


1 


WDTBoot 


boot 


R[12] 


SR = 57b 


4.10 


RFB[3] 


1 


GB = 6 


{5} 


boot 


R[13] 


SR = 57b 


4.10 


RFB[4] 


1 


PwrBoot 


{5} 


boot 


R[14] 


SR = 57b 


4.10 


RFB[5] 


1 


Parity Boot 


{5} 


boot 


R[15] 


SR = 57b 


4.10 


DB 


6 


ALUA[10:15 


| F2 = 6 


t2 


R[4:9] 


SR = 33b* 


3.6.3.1 


SB 


6 


ALUA[10:15 


F2 = 5 


t2 


R[10:15] 


SR = 33b* 


3.6.3.1 


MNBR 


16 


ALUA[0:15] 


F2=13b 


t2 


R[0:15] 


SR*37b* 


3.6.3.1 


CycteControl: 
















DBX[2:5] 


4 


ALUA[8:11] 


F2 = 4 


t2 


R[0:3] 


SR = 27b 


3.6.2,3.6.3.1 


MWX 


4 


ALUA[12:15 


| F2 = 4 


t2 


R[4:7] 


SR = 27b 


3.6.2,3.6.3.1 


PCF 


4 


0,ALUA(13:1 


5] F2 = 14b 


t2 


R[12:15] 


SR = 27b 


3.6.4.1 


PCX 


4 


PCF[0:3] 


{6} 


t2 


R[8:11] 


SR = 27b 


3.6.4.1 


RS232 In 


8 


{3} 




- 


R[9:15] 


SR = 37b 


3.9.3 


RS232 Out 


8 


H2[8:15] 


F1=1 


t2 


- 


- 


3.9.3 


Printer In 


16 


{3} 


. 


. 


R[0:15] 


SR = 27b* 


3.9.4 


Printer Out 


16 


ALUA[0:16] 


F2 = 17b 


t2 


- 


• 


3.9.4 


Memory Syndromes: 














Slot A 


8 


{3} 


- 


- 


R[0:7] 


SR = 13b 


5.5 


Slot B 


8 


{3: 


r 


- 


• 


R[8:15] 


SR = 13b 


5.5 
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Notes: 

SR = n means RSEL = n, RMOD = 1, GB means Group B Function 

RShift (F2 = 0) must be asserted 
{1} Register is read in complement form 
{2} Cannot be read directly 
{3} Cannot be loaded directly 

{4} Loaded when an error is detected. Causes a trap to iocation 1 if nonzero 
{5} Loaded when machine is bootstrapped for any reason 
{6} Loaded at t2 of all instructions located at 2001b + 4*n, n = 0-377b. 



Sections: Arithmetic Section 18 



3.2.2 Stkp and SStkp 



Stkp (stackpointer) is an 8-bit register used to address the R memory indirectly. The 
stackpointer is not task- specific, and tasks other than the emulator which use it must save 
and restore its value. The stackpointer may be read onto the R bus (in complement form) 
and loaded from ALUA as described in Table 3.1. The only way in which a task can address 
the entire R memory is via the stackpointer. 

When the stackpointer is used to address the R memory (when RSEL[0:1] = 0, RSEL[4:5]=3), 
it may be incremented at t2 under control of RSEL[2:3] and the function StackShift (F2 = 3). 
The amount of the increment is shown in Table 3.2.2. The increment is done modulo 16. 
Note that the function StackShift is also sent to controllers on the backplane as lOStrobe, 
which means that I/O microcode cannot increment Stkp by +2, +3, or -3 in one 
microinstruction without generating lOStrobe. The Stkp value used to read the R memory is 
the value before any increment specified by the instruction is done, the value used to write R 
is the incremented value. 





Table 3.2.2 




RSBL[2:3] 


StackShift 


Stkp Increment 











1 





+ 1 


2 





-1 


3 





•2 





1 


+ 2 


1 


1 


+3 


2 


1 





3 


1 


•3 



There are several R locations that cannot be read or written indirectly via the stackpointer 
without causing a fault (see section 4,6). If Stkp«1lb-17b, or if Stkp = and the current 
microinstruction is reading from the stack, a StackOvf fault will be caused. The intent here 
is to place the Mesa stack in locations 1«10b, and use this mechanism to generate the Mesa 
StackOverflow trap. The size of the stack is set by a PROM on the ALU board. (Note: The 

precise condition corresponding to "Instruction Reading Stack" is Meminst' and ALUF#0 and RSEL{0:1] = 
and RMOO and RSEL[4:5] = 3. In particular, this means that an instruction must select R as one of the ALU 
inputs for StackOvf to be detected.) 

The register SStkp (Saved Stkp) is provided to save the value of the stackpointer at the start 
of execution of every Mesa bytecode. This is necessary since the bytecode may cause a 
trap, and it is essential to be able to reset the state of the machine to its pre-trap value if this 
occurs. SStkp is loaded from Stkp at t2 of microinstructions located at 2001b + 4*n (n=0- 
377b). These locations contain the first microinstruction of every bytecode. SStkp may be 
read onto the R bus as indicated in Table 3.1. 

3.3 T Register 

T is a task-specific temporary register (i.e. there are 16 copies of T, one per task). T is read 
during cycleO of an instruction, and the value read is loaded into H2 and used as one ALU 
operand if the BSEL field of the microinstruction equals 2 or 3. T will be loaded from the 
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output of the ALU (actually, from the H3P register) during cycle3 if the microinstruction bit 
LT is asserted. There is logic to bypass T so that if a write is specified during one 
instruction, the data may be used during the following instruction. This logic addresses T 
from CTask during CycleO and from CTD during Cyclel . [Note: Since writes of T are piped across 
memory references, CTD (which addresses T for writing) is not clocked if Memlnst = 1. Also, if T is loaded by 
a microinstruction immediately preceding a memory reference and read by the instruction immediately following 
the memory reference, the reader will get the wrong value, since the ALU output will no longer contain the value 
about to be written into T, but bypassing will still be invoked. This situation must be avoided by the 
programmer. ] 

3.4 Constants 

The processor provides two forms of constants which may be used as ALU operands. If 
BSEL = 0, the eight-bit concatenation of the F1 and F2 fields is loaded into bits 8-15 of H2 at 
t1, and is used as the ALU operand during cyclel and cycle2. Bits 0-7 of H2 are zeroed. If 
BSEL = 1, F1 and F2 are placed in bits 0-7 of H2, and bits 8-15 are zeroed. When a constant 
is specified in an instruction, the normal actions of F1 and F2 are disabled. 

3.5 Arithmetic/Logic Unit 

The ALU is a 74S181, which can perform a number of arithmetic functions, as well as all the 
logical functions of two input variables. The ALU inputs are the output of the H2 register 
(which contains the datum selected by the BSEL field of the microinstruction), and the ALUA 
bus, which is the output of the cycler/masker. In normal instructions, the H1 and H2 
registers are loaded at t1 , and the results of the ALU operation are loaded into H3P and the 
RESULT register at t3. The ALUA bus is stable before t2, and is used as the source of data 
for a number of the discrete registers in the processor. The control signals for the ALU are 
normally taken from the ALUF field of the microinstruction. This four bit field is mapped into 
the control signals required by the 74S181 by a PROM which implements sixteen of the most 
frequently used ALU functions. The functions provided by the ALUF field are: 

Table 3.5 

ALUF ALUOut = 

H2 

1 ALUA 

2 ALUA and H2 

3 ALUA or H2 

4 ALUA xor H2 

5 ALUA and not H2 

6 ALUA or not H2 

7 ALUA xnor H2 

8 ALUA + Cy1 

9 ALUA + H2 + CyO 

10 ALUA + H2 + Cy1 

11 ALUA-Cy1 

12 ALUA-H2-CyO 

13 ALUA-H2-Cy1 

14 unassigned 

15 use SALUF for ALU function 

In instructions in which the function UseCoutAsCin is not used, Cy0 = and Cy1 = 1 in Tables 
3.5 and 3.5.1. If UseCoutAsCin is asserted, CyO = Cy1 = Result[1], i.e. the carry bit from 
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the last ALU operation is used as the ALU carry in. 

3-5.1 SALUF 

In addition to the functions provided by the ALUF field, there is an 8-bit register SALUF 
which may be loaded from H2[Q8:15] under control of an F decode, and subsequently used 
to execute any function of which the SN74S181 is capable. Six bits of this register are used 
to supply the six bits required by the ALU chips as described in Table 3.5.1, the remaining 
two bits are used by the BitBLT primitives. 
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Table 3.5.1 






H2[10:1 


1 5] Function 









* ALUA + CyO 






1 


• ALUA + Cy1 






2 


* (ALUA or H2') 


+ CyO 




3 


(ALUA or H2') + 


Cy1 




4 


* (ALUA or H2) 


+ CyO 




5 


(ALUA or H2) + 


Cy1 




6 


- 1 + CyO 






7 


- 1 + Cy1 






10b 


(ALUA and H2) + ALUA ♦ CyO 




11b 


(ALUA and H2) + ALUA + Cy1 




12b 


(ALUA or H2') + 


(ALUA and H2) + CyO 


13b 


(ALUA or H2') + 


(ALUA and H2) + Cy1 


14b 


* ALUA + H2 + CyO 




15b 


* ALUA + H2 + Cy1 




16b 


(ALUA and H2) - 


1 + CyO 




17b 


* (ALUA and H2) 


- 1 + Cyl 




20b 


(ALUA and H2*) 


+ ALUA + CyO 




21b 


(ALUA and H2') 


+ ALUA + Cy1 




22b 


" ALUA - H2 - 


1 + CyO 




23b 


• ALUA - H2 - 


1 + Cy1 




24b 


(ALUA or H2) ♦ 


(ALUA and H2') - 


¥ CyO 


25b 


(ALUA or H2) + 


(ALUA and H2') • 


► Cy1 


26b 


(ALUA and H2*) ■ 


■ 1 + CyO 




27b 


*(ALUA and H2') 


- 1 + Cy1 




30b 


ALUA + ALUA + CyO 




31b 


ALUA + ALUA + Cy1 




32b 


(ALUA or H2') + 


ALUA + CyO 




33b 


(ALUA or H2'j + 


ALUA + Cy1 




34b 


(ALUA or H2) + 


ALUA + CyO 




35b 


(ALUA or H2) + 


ALUA + Cy1 




36b 


* ALUA - 1 + 


CyO 




37b 


* ALUA - 1 + 


Cyl 




40-41 b 


ALUA' 






42-43b 


ALUA' and H2 






44-45b 


ALUA' and H2' 






46-47b 


zero 






60-51 b 


ALUA' or H2 






52-53b 


• H2 






54-55b 


* ALUA xor H2' 






56-57b 


* ALUA and H2 






60-61 b 


ALUA' or H2' 






62-63b 


* ALUA xor H2 






64-65b 


H2' 






66-67b 


* ALUA and H2' 






70-71 b 


- 1 






72-73b 


• ALUA or H2 






74-75b 


* ALUA or H2' 






76-77b 


* ALUA 







* Normal ALUF field functions 



3.5.2 Result Register 



The four condition bits ALIKO, ALUCarry, ALU#0 and NoOverflow are held in the Result 
register, which is normally loaded at t3 of every instruction (this register is not task-specific). 
Normally, it is expected that branches on these conditions will be done in the instruction 
following the ALU operation which causes the condition. There is a function (FreezeResult, 
F2 = 2) which inhibits the loading of the register so that branches which test the ALU result 
can be deferred if desired. The Result register is not loaded with the results of an ALU 
operation if FreezeResult is executed during that instruction. The function UseCOutAsCin, 
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F2*16b, is provided to use ALUCarry as the carry into the ALU. 

The Result register is read onto R[0:3] using RSEL*7, RM0D = 1. The register is read in 
complement form. The Result register is loaded at t3 from ALUOUT[00:03] by the Group B 
function Restore (11b). This function is provided primarily to restore the state of the 
machine after processing of a fault. 

Note: Since Result is not task specific, it cannot be used to return a value from a subroutine (since the 
RETURN may switch tasks). 

3.6 Cycler/Masker 

The cycler/masker is provided for three purposes: 

1) To provide efficient implementation of the Mesa Read Field, WriteField, ReadString, WriteString, and 
Shift instructions. 

2) To provide the capability of rapidly unpacking (and optionally dispatching on the value of) fields in 
an R register or other R bus source. 

3) To provide an efficient implementation of the BitBLT operation. 

The cycler/masker is controlled in a number of ways, which will be described in detail 
below. 

3.6.1 Short Fields 

When BSEL = 3, F1 and F2 are concatenated and used as an 8-bit Short Field Descriptor 
which is used to control the cycler/masker. In all short field operations, H2 is loaded from 
T. 

The values of F1„F2 and their associated operations, as well as the assembler macros used 
to perform the short field operations are: 

LDF[R8source,POS,SJZE] is used to right-justify any field. POS and SIZE are octal constants which specify the 
first bit and the width of the field. RBsource is any register which can be placed on the Rbus. 






17b: 


16 


1-bit 


fields 


20b 


36b: 


15 


2-bit 


fields 


37b 


54b: 


14 


3-bit 


fields 


55b 


71b: 


13 


4-bit 


fields 


72b 


105b: 


12 


5-bit 


fields 


106b 


120b: 


11 


6-bit 


fields 


121b 


132b: 


10 


7-bit 


fields 


133b 


143b: 


9 


8-bit 


fields 


*!d4b 


153b: 


8 


9-bit 


fields 


154b 


162b: 


7 


10-bit 


fieics 


163b 


170b: 


6 


11 -bit 


fields 


171b 


•175b: 


5 


12-bit 


fields 


176b 


■201b: 


4 


13-bit 


fields 


202b 


•204b: 


3 


14-bit 


fields 


205b 


•206b: 


2 


15-bit 


fields 



starting at bit 0, 1, 

starting at bit 0, 1, 

starting at bit 0, 1, 

starting at bit 0, 1, 

starting at bit 0, 1, 

starting at bit 0. 1, 

starting at bit 0, 1, 

starting at bit 0, 1 

starting at bit 0. i 

starting at bit 0. 1. 

starting at bit 0, 1 

starting at bit 0, 

starting at bit 0, 

starting at bit 0, 1 

starting at bit 0, 1 



1, 

1, 2, 
2 



15 

14 
13 
12 
11 
10 



8 
7 

6 

5 

4 



DISPATCH(RBsource,POS,SIZE] is used to load APC with the selected 
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field with SIZE = < 4 bits in preparation for a dispatch operation in the next microinstruction. 



207b -226b: 

227b -245b: 

246b -263b: 

264b -300b: 



16 1-bit fields starting at bit 0, 1, ..., 17 

16 2-bit fields starting at bit 0, 1 16 

14 3-bit fields starting at bit 0, 1, ..., 15 

13 4-bit fields starting at bit 0, 1 14 



RSH[RBsource,shiftcount] right-shifts RBsource by shiftcount 1 to 15. 

uses LDF[RBsource,0,(16 - shiftcount)] codes 

LSH{RBsource,shrftcount] left-shifts RBsource by shiftcount 1 to 15. 

301b -317b: 15 left shifts of 1, ..., 15 bits 

LCY[RBsource,shiftcount] left-cycles RBsource by shiftcount 1 to 15. 

320b -336b: 15 left cycles of 1, ..., 15 bits 

RCY[RBsource,shiftcount] right-cycles RBsource by shiftcount 1 to 15. 

uses LCY[RBsource,{16 - shiftcount)] codes 

RHMASKfRBsource] is RBsource & 377b 

uses LDF[RBsource,8,8] code 

LHMASK[RBsource] is RBsource & 177400b 

337b: RBsource & 177400b 

ZERO is zero 

340b: zero 

FixVA[RBsource] is provided to propagate bits and 8 of the high half of a memory base register pair into bits 1 
and 9, so that the test for virtual addresses >22 bits will work properly. 

341b: RSH[RBSource,1] and 40100b 

Fields 342-355 are provided to mask the value in H1. The intent is to mask a register containing -1 to produce 
the indicated small constant on ALUA. 

342b: RBsource and 2 

343b: RBsource and 4 

344b: RBsource and 5 

345b: RBsource and 6 

346b: RBsource and 10b 

347b: RBsource and -2b 

350b: RBsource and -3b 

351b: RBsource and -4b 

352b: RBsource and -5b 

353b: RBsource and -6b 

354b: RBsource and -7b 

355b: RBsource and -10b 
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Field 356 places bits 0-3 into bits 8-11, and masks out the rest of the word. 

356b: RSH(RBsource,10b] and 360b 

The remaining fields have no effect 

3.6.2 Mesa Field Operations 

A Mesa field descriptor is an eight bit quantity in which bits 0:3 indicate the bit number of 
the first (leftmost) bit in the field, and bits 4:7 indicate the width of the field in bits minus 1. 
The cycler contains logic to optimize the Mesa RF (read field) and WF (write field) 
instructions by controlling the cycler/masker directly from a field descriptor. 

The RF function (F1 = 14b) causes the cycler to right justify the quantity from R, and masks 
out all but the rightmost width bits of the field. Precisely, RF does: 

ALUA * H1 LCYtDBX(2:5] + MWX[0:3] + 1] and MASK{MWX(0:3]], 

where MASK[x] contains 1's in bits 15-x through 15. 

The WFA operation takes a source word from R, shifts it to its correct position in the 
destination, and masks out all bits except those in the field. A second microinstruction 
containing WFB is then used to insert the field into the destination word. WFA is F1 =11b, 
WFB is Fl=13b. Precisely, WFA does: 

ALUA «- H1 LCY[15 • (DBX(2:5] + MWX(0:3])] and MASK1(DBX[2:5], MWX[0:3]], 

where MASK1[x,y] contains 1's in bits x through x + y. WFB does: 

ALUA <- H1 and not MASK1[DBX{2:5], MWX(0:3]]. 

The CycleControl register is loaded at t2 from ALUA[8:15] by the function CycleControl <- 
ALUA (F2«4). CycleControl is not a discrete register, but is the concatenation of DBX[2:5] 
and MWX(0:3]. These two registers are also used by the BitBLT operations. Although 
CycleControl can be read onto the R bus (RSEL = 27b, RMOD = 1), tasks other than the 
emulator should not attempt to use CycleControl by saving its value, using it for an 
operation, then restoring the value, all between task switches. The reason for this is that 
when CycleControl is loaded, SBX[0:5] and DBX[0:1] are also loaded with information which 
is a function of the SB and DB registers, so these registers would also have to be saved and 
restored. Thus, although it is possible to define a set of conventions for the emulator 
microde which would allow another task to save and restore SBX, DBX, and MWX, this would 
be a time consuming operation. 
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3.6.3 BitBLT 

The purpose of the BitBLT (bit boundary block transfer) operation is to move information 
from one region of main storage to another, modifying the information at the destination as 
the transfer is done. The location of the source and destination areas are specified to a 
precision of one bit. The operation moves a number of items which are contiguous fields of 
fixed width separated in storage by a fixed increment (width and increment also have a 
precision of one bit). An operation of the form dest<-dest op src is done, where op is any 
logical function. 

Since the BitBLT operation is time consuming, a significant amount of hardware exists in the 
processor to optimize its operation. The transfer uses two quadword areas in R, one for the 
source and one for the destination. Two six-bit registers (SBX and DBX) are used to index 
these buffers; the most significant two bits of these registers select a word within the buffer, 
the low four bits point to a bit within the selected word. The R addressing logic uses the 
two most significant bits of these registers to index a word in R, the cycler/masker is 
controlled by the low four bits of the registers. Each time the inner loop of the microcode 
transfers a portion of an item (a "chunk") from source to destination, the registers are 
incremented by the number of bits in the chunk. The number of bits transferred by a single 
iteration of the inner loop (the chunk width) is determined by hardware which examines the 
values of SB and DB, and transfers as many bits as possible without overflowing a word 
boundary or exhausting the item. 

The microcode for the BitBLT operation is divided into three major sections: 

1) Startup and termination, which sets up the parameters of the instruction in a form suitable for the 
microcode, and handles the final state after the transfer is complete. 

2) the inner loop, which does the transfer. 

3) Routines which refill the source and destination quadword buffers from main storage, and update 
counts and addresses. 

The operation of the inner loop will be described in a subsequent section. 

3.6.3.1 BitBLT Registers 

The DO contains six registers whose primary purpose is to support BitBLT. The 
interconnection of these registers is shown in Figure 2.4, and their characteristics are 
summarized in Table 3.1. This section describes them in detail. 

The registers are divided into two groups or levels. During each iteration of the two 
instruction inner loop of BitBLT, SB, MNBR. and DB (the main level) are clocked at t2 of the 
first instruction, and SBX, MWX, and DBX (the "X" level") are clocked at t2 of the second 
instruction. SB and DB are 6-bit pointers into two 64 bit (4 word) buffers in R, one for the 
source information and the other for the destination information. MNBR contains the 
(negative of the) number of bits remaining in the current item. During each iteration of the 
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inner loop, a quantity (MW) is calculated which represents the maximum amount by which 
the source and destination pointers may be advanced without crossing a source or 
destination word boundary or exhausting the item. MW is the number of bits (precisely, it is 
the number of bits-1) which will be transferred by one iteration of the inner loop. 

Figure 3.6.1 shows the process in detail. At point A, SB, DB, and MNBR are loaded with the 
correct values for iteration n. From these values, MW for iteration n is calculated. At point 
B, SBX and DBX are loaded from SB and DB, MWX is loaded from MW, and iteration n 
begins under control of the X level registers. Between points B and C, MW ( + 1 ) is added to 
SB, DB, and MNBR, and these registers are updated at point C in preparation for the next 
iteration. 



Iteration n-1 



First Instruction 
BBFA 



Second Instruction 
BBFB 



■*!*■ 



Iteration n 



First Instruction 
88FA 

I 



Second Instruction 
BBFB 



*l 



A 



Calculate MW for 
next iteration 



Load DB,SS,MNBR 
for iteration n 



B 



DBX«-08 
SBX«-SB 
MWX+-MW 



C 



DB<-DB + MW 
S8«-S8 ♦ MW 
MNBRHMN8R + MW 



Figu re 3.6. 1 BitBLT Inner Loop Timing 



The updating of the main level registers is done at the end of the first instruction of an 
iteration by the BBFA function (F1 =0). BBFA also has other effects, described later. The 
updating of the X level from MW and the main level is done by the functions BBFB (F1 = 12b) 
or BBFBX (Fl»1Sb). 

SB, DB, and MNBR may be read as R bus source (see Table 3.1). When an item begins, SB, 
DB, and MNBR are loaded (from ALUA) with the pointers and count for the item, the 
quadword buffers in R are filled, and the main loop is entered with an instruction which 
includes BBFBX (this advances the main level into the X level in preparation for the first 
iteration). 

During the first instruction of each iteration, the BBFA function sets up a 3-bit dispatch 
based on the values of SB. DB and MNBR for the next iteration. This dispatch determines 
whether or not the loop is to terminate, and if so, how. The conditions tested are: 

1) If MNBR is about to overflow (i.e., if the most significant bit of the adder feeding MNBR = 0), the 
current item is exhausted. 



2) If SB is about to overflow (i.e., \i the adder feeding SB produces a carry), the source quadword 
buffer is exhausted and must be refilled. 
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3) If DB is about to become zero, the destination buffer is filled and must be stored (and possibly 
refilled). 

4) If none of the above occurs, another iteration should be done. 

Note that if the buffers require refill, it is not necessary for the refill microcode to modify any 
of the registers, since they will have been set up properly for the iteration following the refill 
by the BBFB function in the second instruction of the loop. The various conditions are 
encoded into the dispatch value generated by BBFA as follows: 

Dispatch Value Meaning 

3 Item Exhausted (MNBR about to become zero) 

4 SB and DB Exhausted 

5 SB Exhausted 

6 DB Exhausted 

7 Continue 

Values 0-2 cannot occur. 
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3.6.3.2 Transfer Inner Loop 

The BitBLT inner loop transfers as much of one word as possible between the source and 
destination buffers. This number is the minimum of (1) the number of bits required to reach 
the next source word boundary (16-SB(2:5]), (2) the number of bits required to reach the 
next destination word boundary (16-DB[2:5]), and (3) the number of bits remaining in the 
current item (-MNBR). This quantity is calculated by PROMS from the registers SB, DB, and 
MNBR, and is loaded into the register MWX (precisely, MWX*-MIN(...) -1) when BBFB or 
BBFBX is executed. The BBFA function (F1 =0), left-cycles and masks the source data (from 
R) in the cycler masker. The cycle count is SBX-DBX, and the source mask extends from bit 
DBX to bit DBX + MWX. Figure 3.6.2 illustrates the source and destination words and the 
values of SBX and DBX before and after a single iteration of the BitBLT loop. 

Before BitBLT Loop: 
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Figure 3.6.2 BitBLT Shifts and Masking 
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In addition to the bits that control the ALU, the SALUF register contains two control bits, MA 
and MB, which are used by the BitBLT operation. MA controls the data on the T (H2) side of 
the ALU during BBFA. If MA ■ 1 during BBFA, bit positions in the ALU H2 input word not 
covered by the source mask are filled with Vs. If MA = 0, these bits are filled with O's. This 
will occur even though the BSEL field of the instruction specifies T as the input to H2 (T is 
disabled by special logic). The idea here is that the first instruction of the BitBLT loop will 
specify T<-R OR T, BBFA, DBLGOTO[X,Y,MB] and the word which is placed in T will contain 
the proper field of the source, correctly aligned with the destination, filled with Vs if MA = 1, 
or with O's if MA = 0. The second instruction of the BitBLT loop will do dest<-f(dest,T) where 
f is some bitwise logical function (set up in SALUF before the transfer is begun). If 
f(dest,1) = dest (e.g., f = AND), MA should be initialized to 1, which will cause bits in the 
destination that are not a part of the operation (i.e., not covered by the source mask) to be 
preserved. If, on the other hand, f(dest,0) = dest (e.g., f = OR), MA should be initialized to 0, 
again preserving unused destination bits. 

MB is a flag bit in SALUF, for which a branch test is provided. The intent is to use MB to 
indicate whether or not the bits of the destination covered by the source mask are to be 
cleared before combining them with the source data (in T). The first instruction of the 
BitBLT loop will contain a branch on MB. If MB = 1 , indicating that the destination bits are to 
be cleared, the branch will send control to an instruction that does dest<-f(dest,T), BBFB. If 
the destination bits are not to be cleared, the other arm of the conditional will be an 
instruction which does dest<-f(dest,T), BBFBX. Both BBFB and BBFBX load the X-levei 
registers, but BBFB applies the complement of the source mask to the destination data, 
BBFBX does not. 

To summarize, BBFA does: 

1) ALUA* H1 LeftCycle [SBX-DBX] and MASK (MASK = 1's in bits DBX through DBX + MWX) 

2) H2- if MA then not MASK else 

3) APC<- dispatch value for loop control (see section 3.6.3.1) 
4} MNBR«-MNBR+MWX + 1 

5) SB<-SB + MWX + 1 

6) DB«-DB + MWX + 1 

BBFB and BBFBX do: 

1) SBX<-SB 

2) DBX-DB 

3) MWX<-MIN[(16-SB[2:5J), (16-DB(2:5]). -MNBRJ-1 

In addition. BBFB (not BBFBX) does: 

4) ALUA<-H1 and not MASK 
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3.6.4 Mesa Instruction and Operand Access 

The DO contains logic to buffer eight bytes from the instruction stream and deliver them to 
the control section as dispatch values, or to the arithmetic unit as data. The data from the 
instruction stream is held in a four word area in the R memory, and the four-bit register PCF 
is used to index this area. The least significant bit of PCF is used to control the 
cycler/masker during a Nextlnst or NextData function, and PCF[1:2] replaces the two least 
significant bits of the R address when RM0D*1, RSEL[4:53 = 0. PCF[Q] is a flag bit which 
indicates that the instruction buffer has been exhausted. 

The function NextData (F = l7b) is provided to access the next byte of the instruction buffer 
in R as an 8-bit operand. It does: 

1) If PCF{0] s 1 , abort the instruction and trap to location (see Section 4.4) 

2) ALUA{8:15h if PCf[Z] then H1 [8:15] else H1 [0:7]; ALUA{0:7]-0 

3) PCF-PCF + 1 

An instruction containing NextData must specify a CALL in its JC field. Normally, CALLs 
save (C1A + 1 mod 16) in the return link register TPC. When a NextData or Nextlnst traps, 
the increment is disabled by the hardware, so the buffer refill microcode can simply RETURN 
to reexecute the Nextlnst/NextData. 

The Nextlnst function (F1a16b) is used in the next-to-last microinstruction of a Mesa 
bytecode. The last instruction of a bytecode is a special RETURN. Nextlnst starts a 
dispatch on the next available byte in the instruction buffer (the byte pointed to by PCF). It 
loads APC with (ALU A or 2001b), providing that HTASK = 0. If HTASK #0 (because another 
task is requesting a wakeup), APC is loaded with TPC[HTASK], and the RETURN in the 
following microinstruction will cause a task switch. 

In addition to (conditionally) loading APC, Nextlnst also loads the 8-bit ByteCode register 
from ALUA[6:13]. When a RETURN instruction with JA.7 = 1 is executed, the 12-bit quantity 
(2001b + 4*ByteCode) is written into TPC[CTASK] during CycleO. This feature is provided 
so that the RETURN in the last microinstruction of a bytecode can task switch and still 
preserve the dispatch address generated by the Nextlnst. When control returns to task 
after the higher priority task has run, execution will resume at the first microinstruction of the 
next bytecode. 

In addition to providing normal instruction dispatching, Nextlnst also tests for interrupts 
generated by I/O microcode. Bit 12 of the RS232 output register (IntPending) is inspected 
by the logic that generates the mask used by Nextlnst. If IntPending is true, the mask is 
forced to 0. which will cause control to go to the code for bytecode (Noop), rather than to 
the normal next instruction. A branch is provided on IntPending, so that the microcode for 
Noop can determine whether it got control due to an interrupt or by executing a zero from 
the instruction stream. The intent is that the I/O controllers wishing to interrupt the Mesa 
emulator will OR a one into IntPending, which will cause an interrupt at the completion of 
the next bytecode. The Noop microcode will clear the bit and cause the interrupt. [Note: Bit 
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12 of the RS232 register is used solely for convenience of implementation. Since this register has other 
purposes, a copy of it must be kept in R. I/O controllers will OR into the copy, then load the real register from 
the copy. The Noop code will mask out the bit in the copy, then load the real register to clear IntPending.] 



In detail, Nextlnst does: 

1) If PCF{0J = 1 abort the instruction and trap to location (see Section 4.4) 

2) ALUA[6:13]«- H . not IntPending then (if PCF[3] then H1 [8:15] else H1[0:7]) else 0; 
ALUA[0:5]«-ALUA[14:15]*-0 

3) APC[2:9]<-if HTASK = then (ALUA or 2001b) else TPC[HTASK] 

4) ByteCode[0:7] «■ ALUA[6:13] 

5) PCF<-PCF + 1 

Like NextData's, instructions containing Nextlnst must specify CALL in their JC fields, so that 
if they trap, they will be reexecuted when the trap handler returns. Because of the 
arrangement of the Nextlnst dispatch bits, the microcode for each Mesa opcode must begin 
at address (2001b + 4*Opcode). 

3.6.4.1 PCX 

The PCX register is provided to hold the low order three bits of the Mesa program counter 
for the bytecode currently being executed by the Mesa emulator. If a bytecode causes a 
trap, this information must be recovered so that the instruction can be restarted when the 
(Mesa) trap handler has corrected the situation that caused the trap. PCX is loaded from 
PCF at t2 of all microinstructions located at 2001b + 4*n (n= 0-377b). 

The first instruction of a bytecode will be aborted if the memory system has not finished 
mapping an emulator memory reference. The feature is provided so that the effects of faults 
will not propagate across instruction boundaries. 

3.7 Parity Register 

The DO checks parity on every read of the R memory, and on the microinstruction in MIR 
[Note: Parity is not checked when the control store is read as data]. In addition, a number of error 

conditions are detected by the memory. When any of these errors occur, a fault is caused, 
and task 15 gets control as described in Section 4.6. 

To allow the fault handling microcode to determine the reason for the fault, a four-bit Parity 
register is provided. This register is read as an R dus source using RSEL = 57b, RMOD = 1. 
The significant bits are: 
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Bit Meaning 

4 Stack Overflow 

5 Control Store Parity Error 

6 R memory Parity Error 

7 Memory Fault 

This register is cleared when the DO is bootstrapped or when the function Reset Errors 
(Groups = 1) is executed. 

It is not always possible to recover the R address or the control store address that caused 
the error, sirjfce one microinstruction is executed between the one that generated the error 
and the initiation of the fault. 

A memory fault may indicate an error, or may be associated with a page fault or write 
protect violation. Task 15 must determine the cause of the fault as described in Section 5.5. 

If task 15 is active and a fault occurs, the machine is bootstrapped. 
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3.8 Special Functions 

Table 3.8 summarizes the F1 and F2 decodes. With the following exceptions, the F1 and F2 
fields are independent and may both be used in a single microinstruction: 

1) If BBFA (F1=0) is used, F2 must be 0. 

2) LoadPage(F2] uses F2 as a 4-bit constant. 

3) Group B (F1=7) selects 16 secondary functions encoded in the F2 field. 

4) During memory reference instructions, F1's are not available. In addition, if DF2=1, F2 is used as 
a 4-bit displacement rather than as a function. 





Table 


3.8 






Function 


Decodes 




Code 


F1 


F2 


Group B 


00 


BBFA* 


RegShift 


unused 


01 


RS232* H2 


Stkp<- ALUA 


ResetErrors 


02 


LoadTimer[ALUA] 


FreezeResult 


IncMPanel 


03 


AddToTimer[ALUA] 


StackShift/IOStrobe 


ClrMPanel 


04 


unused 


CycleControl* ALUA 


GenSRQock 


05 


LoadPage[F2] 


SB<- ALUA 


ResetWDT 


06 


unused 


DB«- ALUA 


Boot 


07 


Group B 


SpareF2 


Breakpoint 


10 


no-op 


BranchShift 


APC&APCTask* ALUA 


11 


WFA 


SALUF<- H2 


Restore 


12 


BBFB 


no-op 


ResetFault 


13 


WFB 


MNBR<- ALUA 


UseCTask 


14 


RF 


PCF<- ALUA 


WriteCS0&2 


15 


BBFBX 


ResetMemErrs 


WriteCSl 


16 


Nextlnst 


UseCOutAsCin 


ReadCS 


17 


NextData 


Printer* ALUA 


DOOff 



•BBFA requires F2 to be RegShift 
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3.9 Miscellaneous Registers 

The 00 processor includes a number of miscellaneous registers, described in detail in this 
section. 

3.9.1 Watchdog Timer 

The DO contains a watchdog timer to ensure that infinite loops cannot hang the machine 
forever. The timer is a one-shot multivibrator with a time constant of -100 ms. When the 
machine is bootstrapped, the watchdog timer is cleared. The timer is started by the function 
ResetWDT (GB = 5), and once this function has been executed after a bootstrap operation, it 
must be executed at least every 100ms, or the DO will be bootstrapped. 

3.9.2 Power Monitoring 

The DO processor requires only +5V for its operation, but its power supply provides -5V, 
+ 12V, and +24V for the main memory and peripherals. The MISC board contains three 
sensors for these voltages which indicate that they are approximately correct. The sensors 
are read to the R bus with RSEL - 37b, RMOD » RegShift = 1. The bits have the 
following significance: 

Bit Meaning 



5 


1 *> +12 ok 


6 


1 => +24 ok 


7 


«> -5 ok 



3.9.3 RS232 Interface 

The RS232 interface consists of an output register, an input register, and level converters. 
All modem control functions will be implemented in microcode, although the hardware 
provides assistance in timing the delivery of the primary serial data stream. Connection to 
an external modem is made via a 25pin male D-shell connector on the rear edge of the Misc 
board. The output register is loaded from H2 by the function RS232 <- H2 (F1 =1). Bits 8 
through 10 of the output register are transmitted directly on the lines (after level conversion), 
but bit 15 is latched as NextBitToGo and transmitted at the next Send signal generated by a 
timer (see section 3.10). The drivers are arranged so that a "1" in H2 corresponds to a 
negative voltage (mark, or control function OFF) on the lines. Bit 1 1 of this register is used 
for the signal SetTime (see 3.9.6), and bit 12 is the signal IntPending (see 3.6.4). Bits 0-7 
and 13-14 are not used. 

The relationship between bits in H2, RS232 standard signal names, and connector pins is as 
follows: 
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Bit RS232 Name 


Connector Pin Number 


8 Request To Send 

9 Spare 

10 Data Terminal Ready 
15 Transmitted Data* 
•Synchronized by timer Send 


4 
11 
20 
2 
function 



RS232 input is handled similarly. The received data is sampled by a timer, and the sampled 
bit and all other modem status signals are read directly onto the R bus with RSEL = 37b, 
RMOD « RegShift = 1 . The receivers are arranged so that a low voltage (mark) on the line is 
read as a "1" on R. The relationship between R bits, signal names, and connector pins is: 



Bit 


RS232 Name Cor 


8 


Received Data* 3 


9 


Clear To Send 5 


10 


Data Set Ready 6 


11 


Carrier Detect 8 


12 


TXClock 15 


13 


RCVCIock 16 


14 


LoopBack for Transmitted Data 


15 


Ring Indicator 22 


•Latched 


by timer Sample function 



Connector Pin Number 



In addition to being read onto R, the transmitter and receiver clocks (pins 15 and 16) are 
also used by the timer logic to sample and send the transmitted data to a synchronous 
modem, as described in section 3.10. 
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3,9,4 Printer Interface 

The printer interface consists of eight output lines, five input lines, and eight bidirectional tri- 
state lines. Connection is made to a 37-pin femaie D-shell connector on the rear of the Misc 
board. 

The output register is loaded from ALUA[0:15] by the function Printer <- ALUA (F1 »l7b). 
The most significant eight bits of this register are sent directly on the lines in pseudo- 
differential form (the complement of each bit is also sent, both at TTL levels). Bit 7 of the 
output register controls the gating of register bits 8-15 onto the bidirectional data bus. If this 
bit is 0, the outputs will be enabled to the bus. The correspondence between ALUA bits, 
signal names, and pin numbers on the 37-pin connector is: 



ALUA bit 


Signal Name 


Pir 





PO.O 


20 




PO.O' 


21 


1 


PO.1 


22 




par 


23 


2 


PO.2 


24 




PO.2' 


25 


3 


PO.3 


26 




PO.3' 


27 


4 


PO.4 


28 




P0.4' 


29 


5 


PO.5 


30 




PO.5' 


31 


6 


PO.6 


32 




PO.6' 


33 


7 


PO.7 


34 




PO.T 


35 


8 


PO.O 


1 


9 


PD.1 


2 


10 


PO.2 


3 


11 


P0.3 


4 


12 


P0.4 


5 


13 


PO.5 


6 


14 


PO.6 


7 


15 


PD.7 


8 



The thirteen input lines are read onto the R bus using RSEL = 27b, RMOD = RegShift = 1 . 
The most significant five bits are simple receivers, the least significant bits are the signals 
PD.0-PO.7 (the bidirectional bus). The pin connections for the most significant bits are: 



R bit 


1 
2 
3 

4 



bigna 


I name 


Pir 


P1.0 




9 


P1.1 




10 


PI.2 




11 


PI.3 




12 


PI.4 




13 
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The cable connector has logic ground on pins 17,18,19,36, and 37. Pins 14 and 15 are 
connected to +12 volts through a 10 ohm, .25watt resistor. An LED is connected across 
this resistor so that if excessive current is drawn by external logic, the LED will light. The 
intent is to use this voltage to supply a small amount of logic in external interfaces. 

During system checkout, the printer interface is used to pass data between the DO and the 
Alto used to operate it. A communications protocol for the Alto program (Midas) and a DO 
microprogram (the Kernel) has been designed which supports this communication and also 
allows the Alto to bootstrap the DO. To perform the bootstrap function, pin 11 (PI.2) is 
supplied to the control board as TesterBoot'. Since the machine is bootstrapped when this 
signal is made low, no normal interfaces should make use of this signal. 

The signals Pl.O • PI.4, and PD.O - PD.7 are terminated with 220 ohms to +5, 330 ohms to 
ground. 



3.9.5 Maintenance Panel 

The maintenance panel is provided to display the results of diagnostic tests when more 
sophisticated I/O facilities are malfunctioning, or during the bootstrap process. It consists of 
a four-digit LED display mounted on the front of the DO cabinet. Two functions are provided 
to display information: ClrMPanel (GB = 3) clears the display to 0000, and IncMPanel (GB 
= 2) increments the contents of the panel by one. Since the panel is implemented with slow 
circuitry, these functions should not be issued more frequently than every TBD 
microinstructions. 

The maintenance panel also contains the power control logic for the system. AC power is 
controlled by a solid state relay. This relay is operated by a START and a STOP button on 
the panel. When START is pressed, the SSR is activated. It is latched on by the DO +5V 
supply. As long as START is depressed, the maintenance panel display is incremented at 
high speed, causing it to display 8888 (lamp test). Approximately 150ms. after START is 
released, the processor is booted (PanelBoot). If START is depressed when power is on, the 
machine is also booted. When STOP is depressed, or when the function DOOff (GB = 17b) 
is executed, AC power is turned off. [Note: DOOff is integrated by the power-off logic to reject noise. 
The correct instruction to turn the system off is "DOOff, Goto[.]" ] 

The maintenance panel contains an unswitched pilot power supply to operate the SSR and 
to charge the battery used by the TOD clock. When this supply is on (indicating that the DO 
has AC power), the decimal point adjacent to the units digit of the display will be lit. 

Since hard R or Control Store parity errors will render the processor completely inoperative 
(and unable to display failure information in the display), these conditions are handled 
specially. When either of these bits are on in the Parity register, the panel is incremented 
rapidly (by the hardware), and the center bar of the units and tens digits are disabled. 
Control store parity disbles the units digit, displaying 8880, R parity disables the tens digit, 
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displaying 8808. 

3.9.6 Time of Day Clock 

The maintenance panel contains a time-of-day dock implemented with a Tl TMS1000C 
(CMOS) microprocessor with a crystal controlled clock. The clock is powered by a battery 
which is charged from the pilot supply whenever the system has AC power. The battery will 
operate the clock for approximately one week with power disconnected. 

Whenever the DO has DC power, the clock emits the time as a serial 32-bit number (at 1ms 
per bit) once per second. There is a branch condition in the DO to test the state of this line 
(TimeOut). The standard microcode will provide conversion to some suitable format and an 
interface to Mesa programs. 

The clock is set by sending it a 56-bit quantity as a serial bit stream. Bit 11 of the RS232 
output register (SetTime) is reserved for this purpose. 

In addition to providing time of day, the clock also accumulates total power-on hours for the 
system, and can be set to turn AC power on and boot the system at a predetermined time. 
Details of the clock are provided in Appendix A. 

3.10 Timers 

The DO processor contains logic implementing high resolution timers at the microcode level. 
Up to sixteen timers can be established. A wakeup to the timer task (task 14) occurs when 
any of the timers expires. A timer consists of one or more slots in a sixteen word Timer 
RAM located on the CPU Misc board. Every four machine cycles, the timer control cycles 
into the next timer slot. The slot contains a four bit state and an eight bit data field. A state 
machine calculates a new state and data field value based on the contents of the slot (and 
possibly on other conditions), rewrites the contents of the RAM, and cycles into the next slot. 
In general, the action taken for the timer is to decrement the data field and cause a task 
wakeup when the field is less than zero. The timer continues to decrement even after the 
wakeup is requested, so that accurate timing can be maintained with varying wakeup 
latency. The DO can load a timer with an initial value to be counted down, or it can add a 
value to the data. The add function is used to implement wakeups at precise intervals by 
utilizing the count after wakeup feature. Loading the data field causes a wakeup at an 
interval relative to the time that the load was done. Adding to the field causes a wakeup at 
an interval relative to the last time the counter underflowed. 

Since the timer RAM has 16 slots, and a new slot is accessed every four cycles, the 
resolution of the timer is 6^ cycles. The range of a simole timer Is 128*64 cycles or 8192 
cycles with a 100% overrange. For timers requiring more range, two or more slots can be 
cascaded. When the first slot decrements from -1 to -2, underflow of the timer is saved in a 
Carry flag. The slot immediately following can conditionally decrement its data field based 
on Carry. The wakeup can be generated on the sign bit of the last slot's data. 
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The timer mechanism also provides bit timing for RS-232 communications. The hardware 
can be programmed to Sample the received data bit (or Send the transmitted data bit) and 
cause a wakeup at appropriate intervals for both asynchronous and synchronous protocols. 
The hardware provides double buffered bit-at-a-time access to the RS-232 data. 

Table 3.10 lists the 16 states a timer can be in, and the changes to the data and state fields 
on each round. There are two functions (LoadTimer and AddToTimer) that load a timer slot 
from the ALU A bus. The 16 bits of the ALU A are divided as follows: Bits 0-3 are the new 
state (loaded by both LoadTimer and AddToTimer), bits 4-11 are the new data (or data to be 
added to the current data) and bits 12-15 are the slot number to be loaded. The timer is 
permanently assigned to task 14. When any timer requests a wakeup, the state and data 
fields of the slot, along with its slot number are loaded into a register which can be read as 
an external R source (Timer), and a wakeup is requested. When the microcode reads the 
Timer register, the wakeup request is cleared. Timers which expire while a wakeup request 
is pending for some other slot remain in their current state until the register is read (but they 
continue to decrement). Thus the output register is a resource which can be held by only 
one slot at a time. 
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State 



1 



4 
5 

6 

7 

8 

9 

10 

11 

12 

13 

14 
15 



Table 3.10 

Action 

if Carry then Data^Oata-1,Carry^(DataaO&CafTy) 

if Carry then Data<*0ata-1 

if Data<0 & not WakePending then 

[Wakeup;State«-4] 

if Carry then Data*Data-1 

if Data = 0&Carry then Send 

if Data<0 & not WakePending then 

[Wakeup;State«-4] 

if Carry then Data«-Data-1 

if DataaO&Carry then Sample 

if Data<0 & not WakePending then 

[Wakeup;State<-4] 

do nothing 

Data<-Oata-l; if Data<0 & not WakePending then 
[Wakeup;State«-8] 

if RDaO then State* 13 

if RD a then State**9 

Data«-Data-1 

Data«-0ata-1 ;Cry«»Data ■ 

if XC*0 then [Send;State*-l] 

if XC=1 then State* 10 

Data<-Data-1 

if Data » then Send 

if Data<0 & not WakePending then 

[Wakeup;State<-8] 

Data* Data- 1 

if Data a then Sample 

if Data<0 & not WakePending then 

[Wakeup;State*8] 

if RCsi then [Sample;State*i] 

if RCaO then State*- 14 



Use 

Middle 

Most Significant 

Slow Async Xmit 
Slow Async Rev 



Fast Async Rev 

Sync Rev 
Sync Rev 



Sei 

Carry 

Carry 

Carry 
Carry 



Idle 




Simple Timer 




Fast Async Start Bit 


RD 


Slow Async Start Bit 


RD 


Wait for Reload 




Least Significant 




Sync Xmit 


XC 


Sync Xmit 


XC 


Fast Async Xmit 





RC 
RC 



Hera is now they are used: 

A simple short timer starts in state 5, decrements until it goes negative, then requests a 
wakeup. When the wakeup is accepted, it switches to state 8. 

A two stage timer starts in state 9. The following slot is in state 1. When the first slot 
causes Carry, the following slot decrements. When the second slot underflows, a wakeup is 
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requested. When it is accepted, the second slot's state goes to state 4. 

A multiple stage timer is like a two stage timer except that additional slots in state are 
placed between the first and the last slots (which are initialized to states 9 and 1 
respectively). 

A fast asynchronous RS-232 receiver starts in state 6, looking for the start bit. When it 
occurs, it switches to state 13, and changes into a timer. When the timer elapses (one half 
of a bit time later), the line is sampled, and a wakeup occurs (switching to state 8 when 
accepted). If the sample is still a 0, the start bit is found, and the program adds one bit time 
to the timer, resetting it to state 13. The timer then times out to the middle of the next data 
bit and wakes up again. The RS-232 data bit can be read as one of the bits of the RS-232 
interface. 

A slow asynchronous RS-232 receiver initializes one slot to state 7, and the next slot to state 
3. When the start bit arrives, the first slot changes to state 9 and starts counting down. The 
next slot counts carries in state 3 until it gets to 0, whereupon it samples the line, and wakes 
up. Succeeding bits are timed by a state 9/3 slot pair. 

A fast asynchronous transmitter uses state 12. The data bit (NextBitToGo) is double 
buffered. NextBitToGo is part of the RS232 output register, loaded from H2 by the function 
RS232*-. 

A slow asynchronous transmitter uses a 9/2 pair of slots. 

A synchronous RS232 receiver waits for the low to high transition of the receive clock (RC) 
in state 14, then samples the data and goes to state 1. The data field of the slot should be 
initialized with a negative value, which causes an immediate wakeup. The program resets it 
to state 15, where it waits until it detects the high to low transition of the clock, and then 
reverts to state 14. 

A synchronous RS-232 transmitter uses states 10 and 11 like the receiver uses 14 and 15. 

The state numbers are arranged so that the most significant 2 bits address a 4 input 
multiplexer wired so that its output ("Sel" in the table above) reflects the Carry bit (Carry) for 
states 0-3, the Receive Data line (RD) for state 4-7, the transmit clock (XC) for states 8-11 
and the Receive Clock (RC) for states 12:15. The state machine has 8 inputs: 4 state bits, 
the output of the Sel multiplexer, Data = 0, Data<0 and WakePending. It outputs a new state, 
the control signals to sample the RS232 input line, send the next RS232 output bit, request a 
wakeup, set the Carry bit, and to decrement the data field. 
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40 Control 

4.1 Normal Instruction Sequencing 

w Normal M instructions are those which do not do conditional branches, dispatches, 
subroutine calls or returns. Normal instructions are coded with a Goto (JC » 4) in the Jump 
Control field of the microinstruction. These instructions calculate the address of their 
successor by concatenating the contents of the four bit Page register with the 8 bits of the 
Jump Address (J A) field in the current microinstruction. Thus a normal instruction's 
successor can be any location within the current 256 word page. Crossing pages is done 
with the function LoadPage(F2], which loads the Page register with the F2 field at t2. 
Accessing the Control Store for fetching the next instruction is overlapped with execution of 
the current instruction. Since the successor of an instruction which loads Page is fetched 
before the Page register is modified, the next instruction will be on the current page, its 
successor will be on the new page. 

....,LOADPAGE(3],GOTO(X]; "Instruction on page n 

X: GOTO(Y]; "Also on page n 

Y: ; *Y is on page 3 

At t2, MIR is loaded with the instruction, the Current Instruction Address register CIA is 
loaded with the address of the instruction, and execution of the instruction begins. 
Execution usually requires four cycles, designated cycie0-cycle3, but another instruction is 
started at t2 (at the end of cyclel). Figure 2.5 illustrates the timing of instructions. 

4.2 Conditional Branches 

Branches are two-way tests which send control to one of two locations whose addresses 
differ only in their low order bit. Branch conditions are encoded in the JC[1:2]„JA(07] field. 
There is a function (BranchShift, F2 = 10b) which changes the interpretation of the JC/JA 
field, doubling the number of available branch conditions. Table 4.2 summarizes these 
conditions. When a branch is specified in an instruction, the condition becomes bit 11 of 
the next instruction address. When the branch condition is true, instruction execution is 
extended by one cycle as described in section 2.4. 
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Table 4.2 
Branch Conditions 



JC{1,2]„JA[7] BranchShift Condition 



ALU#0 (Tests ALU result from previous instruction) 

Carry (Tests ALU result from previous instruction) 

ALU<0 (Tests ALU result from previous instruction) 

NoH2Bit8 (Tests value placed in H2.8 by the current instruction) 

R<0 (Tests value placed in H1.0 by the current instruction) 

R Odd (Tests value placed in H1.15 by the current instruction) 

NoAttn (Hag from I/O controllers) 

MB (bit in SALUF) 

IntPending (Interrupt test) 

NoOvf (Tests ALU result from previous instruction) 

BPCChk (Tests PCF[0]) 

Spare 

QWO (Tests result of Pfetch2/Pstore2 in the previous instruction) 

TimeOut (Tests data from TOD clock) 



4.3 Subroutines and Tasking 

JC = 5 specifies a subroutine Call. The address of the successor is calculated exactly as in 
a Goto, but In addition, (CIA + 1) is written into the Task Program Counter (TPC) RAM 
location for the Current task during cycle 0. [Note: Only the low four bits of CIA are incremented.] 
This will be the Return Address for the subroutine. 

At t2 of every instruction, the Alternate Program Counter register APC is loaded with 
TPCfHTask] except as noted below. HTask is the number of the highest priority task 
requesting a wake-up. The read of TPC is done during cycle"!. If CTask = HTask, the 
return address will be loaded into APC at t2. If the next instruction specifies a Return 
(JC = 6), the address for its successor will be the contents of APC. Since the write of TPC 
with the return address is done during cycle of the call, and the read of TPC is done in 
cyclel, the first instruction of a subroutine can do a Return. Thus one instruction 
subroutines are allowed. 

If CTask is not the same as HTask, APC will not contain the return address for the task 
which is running, but will have a return address for the highest priority requesting task and 
control will pass to the task whose return address is in APC. Thus a subroutine return can 
cause a task switch. When APC is loaded with TPC[HTask], the APCTask register is loaded 
with HTask. When the Return is executed, CTask is loaded from APCTask, thus completing 
the TASK function. 



AN subroutine returns will cause a TASK unless the function UseCTask is executed in the 
instruction immediately preceding the Return. UseCTask forces the read of TPC to be 
TPC[CTask] instead of TPCfHTask], thus APC will be loaded with the return address of the 
current task irrespective of the wake-up logic. UseCTask also loads CTask into APCTask so 
that the task number is not changed with the Return. APCTask always contains the task 
number corresponding to the contents of APC. 
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Subroutine return is the only way to cause a TASK. Long sequences of instructions which 
do not call subroutines can do TASKs by replacing two normal instructions (with Gotos) into 
a Call/Return pair. 

Without Task: With Task: 

X: — ,GOTO[Y]; X: CALL{Y]; 

Y: GOTO(2]; X + 1: ; -Returns to here 

Z; ; Y: ,Return; 

Multi-level subroutines can be done with explicit save/restore of the return address in an R 
location. The APC and APCTask registers can be read as an external R source (see Table 
3.1). The UseCTask function forces APC&APCTask to be loaded with TPC[CTask]&CTask. 
This combination is used to save the return address. Another function is available to load 
APC&APCTask with the data on ALUA, which can then be used as the return address. This 
explicit loading of APC and APCTask overides the normal TPC[HTask] load. The coding for 
this is as follows: 

CaJIfSubM]; -1st level call 

; "1st level returns to here 

Subrl: ; 

,UseCTask; "Forces APC to be loaded with return address. 

T<-APC*APCTask; "Save return address In T 

R«-T,Cail(Subr2]; "Save return address in R and call 2nd level 

; "2nd level returns to here 

APC*APCTask«-R; 'Load saved return address into APC 
Return; "Return to main level 

Subr2: 

Return; "Return to 1st level 

The Page register is loaded from the top 4 bits of APC when a Return is executed. Cross- 
page subroutine calling can be done with the LoadPage[F2] function. 



LOADPAGE{3]; "Caller on page n 

,CALL(SubrOnPage3]; "Subroutine on page 3 

; "Returns to page n 

4.4 Dispatches 

Dispatches provide a way of doing a multi-way branch. When a dispatch is specified, the 
value (usually ALUA) is loaded into APC at t2. and the bits involved replace the Page/JA bits 
z z: 4 h3 next instruction. Dispatches are specified in the following ways: 

1) A number of the short field operations extract a field from an R location or other R bus source, and 
load it into APC. The instruction following this must contain a Dispatch directive (JC = 7). This will 
cause the lower 4 bits of the address to be taken from APC, with the remaing address bits coming from 
Page{0:3],JA(0:3]. This results in a 16 way (or fewer) branch. 

2) The Nextlnst function loads APC with the start address of the microcode for each of the 256 Mesa 
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bytecodes. The instruction following the Nextlnst must specify a Return, and all 12 address bits will 
come from APC (See 3.6.4). 

3) The function BBFA does a dispatch based on the number of bits remaining in the current quadword 
buffer in R. The sucessor of the BBFA must specify Dispatch in the JC field. 

4.5 Aborted instructions 

There are several reasons for aborting an instruction: 

1) A NextData or Nextlnst operation attempts to read a byte from the quadword indexed by PCF when 
PCF[0] = 1. 

2) The memory is busy and a memory reference instruction is attempted. 

3) An R location for which a memory reference is pending is specified in an instruction. 

4) A Fault occurs. 

In general, aborting an instruction means that all irreversible actions that the processor 
would have taken will not be done. The net effect is that the instruction is not executed at 
all, including the load of MIR. Thus the instruction will be re-executed, since MIR did not 
change. There are two exceptions to this: The first is that TPC is written with CIA + 1 if 
the aborted instruction specifies a Call. This does not cause any ill effects. 

The other exception is that in case 1 above, MIR is loaded, not with the successor specified 
by the instruction, but rather with ControlStore[0]. In addition, CIA is written into TPC. This 
is esssentially an unanticipated subroutine call to location (a trap). The trap routine 
starting at location refills the instruction buffer and restarts the instruction by executing a 
Return. 

In cases 2 and 3 above, all register loads are inhibited, which will cause the instruction to be 
repeated endlessly until the memory becomes free or the R location is filled or used by the 
memory. 

4.6 Faults 

A fault occurs when the memory detects a page fault, write protect violation, or input data 
parity error, when an internal bus parity error is detected by the processor, or when the 
Breakpoint function is executed. Faults are expected to be infrequent, and are handled by 
a special mechanism since they occur asynchronously with respect to normal 
microinstruction sequencing. 

When a fault occurs, the current instruction is aborted and the signal Fault is generated at 
to. The next address logic is disabled, and a fetch of location 1 is forced. Fault causes the 
loading of CIA to be inhibited, thus freezing the location of the instruction which was 
executing when fault occured. A similar action freezes the Result register. There are two 
versions of the current task register which normally have the same contents, but become 
different while Fault is asserted. The internal CTask register, InCTsk, remains set to 
whatever task number was running when fault occurred. The InCTask register may be read 
as an external R bus source, but CTask cannot. CTask is used to modify the R addresses 
and to address T, and is set to 15 by Fault. Fault also disables the Page register's 
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contribution to the control store address, which forces all instructions of the fault handling 
microcode to be on page until the ResetErrors function is executed. [Note: There is a 
ResetFault function, which only resets Fault, while the function ResetErrors both resets Fault and clears the 
Parity register. Since the Parity register must be cleared before Fault is reset (to avoid another fault), ResetFault 
is obsolete and should not be used.] 

The fault trap code starting at location 1 must first save APC&APCTask since it will be 
overwritten at t2, and then save CIA&CTask (the Internal CTask) as well as the Result and 
Parity registers. If the fault was due to a stack overflow, the code must set the stackpointer 
to a legal value (not or 11 -17b). Then the fault code does a Notify (see below) to force 
task 15 to run, accompanied by the ResetErrors function. ResetErrors turns off Fault, clears 
the Parity register, and releases the freeze on CIA Result., and the Page register. At this 
point, Task 15 is running normally and can examine all the saved state to determine what 
action needs to be taken. When task 15 is finished, it returns to the running program using 
the APC&APCTask <- ALUA function as well as the function Restore. Restore loads 
APC&APCTask with ALUA and loads the Result register with H2. 

The return sequence is: 

T«- Saved ResultRegisten 

APC&APCTask«-SavedCIA*CTask; 

APC&APCTask* Saved APC&APCTask,Restore,Return; 

The first instruction presets T to the saved condition code. The second loads the desired 
return address and task number into APC. The third specifies Return, thus the next 
instruction address will come from APC, and CTask will be loaded with APCTask. At the 
same time as the fetch of the instruction that was aborted when the fault started, APC and 
APCTask are loaded with the value that they had before the fault, and the contents of the 
Result register are restored at t3. 

The fault handling code cannot do anything which could result in a fault. In particular, it 
cannot do any memory references, but must send messages to lower priority tasks to do any 
logging or recovery required as a result of the fault. 

4.7 Notify 

Notify is used to start another task at an arbitrary location. It is done by loading APC and 
APCTask with the address and Task number desired, followed by a Return directive. The 
next instruction after the return will be in the new task, regardless of HTask. 

4.8 Writing and Reading Registers 

APC and APCTask can be 'written with a function, and read as an external R source. CSA 
anc CTask cannot be written explicitly out can oe reaa as an R ous source (CIA is reac in 
complement form). Page can be loaded with a function and read as an external R bus 
source. TPC cannot be written explicitly except by doing a Call. TPC for the current task 
can be read by doing UseCTask, followed by reading APC. TPC for another task can be 
read only by notifying the task at a location containing code to read TPC, then notifying back 
to the original task. 
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4.9 Reading and Loading the Control Store 

Data for writing into the control store comes from a 16 bit register CSIn which is loaded from 
ALUA at t2 of every instruction which does not load APC, and from a 4 bit extension to that 
register which is loaded from H2 every t2. There are two functions which write the three 
sections of the control store as follows: 

T ♦• Data for bits 32-35; 

ALUA «- Data for bits 00-15; 

APC «- Address; 

WriteCS0&2; 

ALUA ' «- Data for bits 16-31; 

APC <- Address; 

WriteCSI; 

There is an additional register CSData, which can be read as an external R bus source, 
which is used in reading the control store. The ReadCS function reads the control store 
location whose address is in APC (same as write). The contents of H2 during the read 
determine which of the 3 sections of control store data are loaded into CSData. A in H2 
causes bits 0-15 to be read into CSData. A 1 causes bits 16-31 to be read, and a 3 causes 
bits 32-35 to be read into CSData[00:03]. 

When an instruction is loaded into the control store, the bits RSEL.O and RSEL.1 must be 
complemented. 

The read and write operations require two more cycles than an ordinary instruction, since 
these operations must address two locations in the control store (the location to be read or 
written and the next instruction). An internal state bit, CSOp, is provided to stretch the write 
and read operations appropriately. 

CSOp is cleared at t2 of every instruction which does not include the functions WriteCS0&2, 
WriteCSI, or ReadCS. In instructions which include one of these functions, CSOp is 
complemented at t2. 

When a control store function is done, if CSOp = 0, the effects are: 

1) The write or read operation is done as specified, using APC as the control store address. 

2) Loading of MIR, CIA, and CTask is inhibited 

3) CSOp is set 

If CSOp = 1 when a control store function is done, 

1) The write or read operation is inhibited 

2) The successor instruction is fetched, using Page.JA for the address. 

3) MIR, CIA, and CTask are loaded normally 

4) CSOp is cleared 



The single write or read microinstruction is thus executed twice, with the read or write taking 
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place during the first execution. Microinstructions that read or write the control store must 
be coded with a RETURN in the JC field, but unlike other RETURNS, the JA field is 
significant. For this reason, the successor of an instruction that reads or writes the control 
store must be placed at an even location unless the contents of the return link (TPC) are 
unimportant. This is because RETURNS with JA.7*1 write into TPC (see 3.6.4). 

4.10 Bootstrapping 

The machine can be bootstrapped by the START button or by the TOD clock, from the test 
hardware, from the watchdog timer, by a function (Boot), or when a parity error occurs while 
task 15 is running. When the boot signal is asserted, a small state machine takes control 
and loads 1024 microinstructions into the Control Store from a 2k x 16 EPROM. Control is 
then transferred to location 0. Since the boot ROM is 32 bits wide, while the control store is 
36 bits wide, 4 bits of control store do not come from the ROM. Instead, the are loaded with 
a constant. The bits are: 

RSEL4 and RSEL5, which are forced to be Vs. This restricts boot code to only 16 R locations, but 
allows reading of external R sources. 

JA[0:1], which are forced to 00. This means that boot code occupies only the first 64 locations of each 
page of the control store. 

The boot state machine uses APC as the source of address for loading the control store, and 
APC is implemented as a counter. The counter bits are wired so that APC[4:11] counts 
modulo 64, then increments APC[Q:3]. At the time the machine is bootstrapped, the 
BootReason register (Table 3.1) is loaded with the reason for the boot, so that the microcode 
can take special action based on this information if it wishes. 
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5-0 Memory 

5.1 Organization 

The memory is organized as a pipeline composed of two stages, MC1 and MC2. Each stage 
has a microprogrammed controller which governs the activities of the stage, and a number 
of data registers which are managed by the controller. Figure 2.3 shows the data paths 
associated with the memory. 

The controller for MC1 contains 256 40-bit control words, the controller for MC2 contains 
256 20-bit words. Most of the complexity of the memory system is contained in these 
controllers, and for this reason, their microcode, annotated with comments, is included as 
Appendix B. 

MC1 is responsible for mapping and for controlling main storage cycles. It controls the 
following items: 

Map memory cycles 

Main storage cycles 

R memory cycles (but R memory writes by MC2 have priority) 

Loading of the storage card data input registers (from H4) 

Loading of the storage card data output registers (from the RAM chips) 

The Idata bus and the H3I register 

The IMux and the H4 register 

MC2 is responsible for the transport of fetched data from the storage card data output 
registers to the appropriate destination. MC2 controls: 

Reading of the storage card data registers 

The H3U register 

The ECC buffer 

The H3C register 

The Odata register 

R write cycles 

5.2 Memory Reference Instructions 

Memory reference microinstructions have special timing and a special format (see figure 2.5) 
in which the ALUF, BSEL, LR, LT, and F1 fields are replaced by a TYPE and SRC/DEST 
field. Once a memory reference has been started by executing a memory reference 
microinstruction, the processor and the memory operate in parallel. The memory will 
eventually transfer data from the source to the destination indicated by the instruction which 
started the reference. A single memory reference inst r uction specifies a!! the information 
required to complete a reference, including the reference type, the source and destination 
for the data, and the virtual address. 
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5.2.1 Reference Types 

The DO provides fifteen different memory operations, selected by the TYPE field of the 
microinstruction. They are: 

PFetch 1/2/4, PStore 1/2/4: 

These operations transfer single, double, or quad words between memory and R. The formation of the 
memory address is described in section 5.2.5. When multiword operations are specified, the least 
significant bit(s) of the address are ignored by the hardware, so the data for an n-word transfer must 
be aligned modulo n in memory. An exception to this rule occurs when doubiewords are transferred to 
or from the stack. Unless the doubieword crosses a quadword boundary, the reference is done as 
specified, even if the words are not aligned. 

The formation of the initial R address is described in section 5.2.2. When more than one word is 
transferred, sequential R locations are used. It is not essential that R locations be double- or quad- 
aligned for the memory to transfer correctly, but if they are not, the R interlock mechanism (section 5.3) 
may be defeated. 

input, Output 

These operations transfer single words beween an I/O device register (section 5.2.4) and an R register. 

lOFetch 4/16, !OStore4/l6: 

These operations transfer four or sixteen word blocks between memory and an I/O device register. The 

data must be quad- or hex-aligned in memory. 

XMap: 

This operation reads and writes the map. It calculates the virtual address in the normal manner, but 
does not cycle the main memory. Instead, it writes the contents of the inital R location specified by the 
instruction into the map entry corresponding to the virtual address, then writes the original contents of 
the map entry into the next three R locations. The format of the data in these registers is shown in 
figure 5.2.1. 

ReadPipe: 

See section 5.5 

Refresh: 

See section 5.7 
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R Address: 



Data Written 
To Map 



Data Read 
From Map 



LOG 



T 



WP DIRTY REF 

sh — i 1 — 



T 



REAL PAGE NUMBER 



3LK.1 



H h 



H h 



+ 



+ 



+ 



3LK.1 



MAIN ROW ADDRESS* 



H h 



+ 



LOG WP DIRTY REF 
SE * * 



MAIN COLUMN ADDRSST 

+ 



1 

CARD* 

I 



BLK.O 



n+1 



n + 2 



n + 3 



1 2 3 4 5 6 7 

' Read in complement form 

Figure 5.2.1 XMap R Register Format 



8 9 10 11 12 13 14 15 



5.2.2 R addresses 

The ten operations that transfer data to or from the R memory generate an Initial R address 
at t2 of the memory reference instruction. This is the address that will be used for the first R 
access done by the operation. If the operation transfers more than one word, sequential R 
locations will be accessed. 



The initial R address is (SRC/DEST or CTASK*16 ) if SRC/DEST#0. CTASK is ORed into 
the high four bits so that up to four I/O controllers of the same type operating at four task 
levels (0,1,2,3 mod 4) can share microcode while using different groups of up to 16 R 
registers per controller. 

If SRC/DEST = 0. Stkp (possibly incremented or decremented by 1) is used for the initial R 
address. The amount by whicn StKp ts incremented or decremented to form the initial R 
address is determined by the ooer£tio n -yo-> and "h^ mr-iber of words involved so that the 
PFetchl/2, PStore1/2, input and Output operations will do pushes and pops to the Mesa 
stack. Stkp itself is also modified by these operations. Table 5.2.2 shows the initial R 
address and the amount by which Stkp is changed for each operation (n is the initial value 
of the Stkp). 
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Table 5.2-2 




Operation 


Final Stkp 


Initial 

R Address 


Pfetehi 


n + 1 


n + 1 


Pstorei 


n-1 


n 


Pfetch2 


n + 2 


n + 1 


Pstore2 


n-2 


n-1 


input 


n + 1 


n + 1 


Output 


n-1 


n 


All Other 


n 


n 



5.2.3 Quadword Overflow 

When a PFetch2 or PStore2 is done to the stack, the hardware inspects the low order two 
bits of the virtual address. If these bits are 11, indicating that the reference crosses a 
quadword boundary, the memory reference is not done, and the flag QWO is set (OWO 
remains set until the next memory reference is started). A branch condition exists to test 
QWO in the microinstruction following the memory reference, so that the operation can be 
reexecuted as two single word operations. When quadword overflow occurs, the 
stackpointer is still updated as shown in Table 5.2.2. 

5.2.4 I/O Register Addresses 

The operations that transfer data to and from I/O devices generate an I/O register address 
at t2 of the memory reference instruction. This address is latched in the laddr register, and 
sent to the controllers on the backplane. For the lOFetch and lOStore operations, this 
address is (SRC/DEST or CTASK'16). For Input and Output, the address is (H2[8:15] or 
CTASK*16). H2 is normally loaded at t1 from T, but if DF2- 1, H2 is loaded from the F2 field 
of the instruction. If DF2 = 0, F2 may be used normally, as may the JC and JA fields of the 
instruction. 

5.2.5 Address Calculation 

The 24-bit virtual address required by the memory is the sum of a 16-bit displacement 
D(0:15] and a 24-bit base pointer which is contained in a pair of R registers. Figure 5.2.5 
shows the formation of an address. The base registers must be set up in advance such that 
if BP[0:23] is a base pointer, BP[8:23] is held in register r, and R register (r or 1) holds 
BP(0:7] in bits 0-7, and BP[0:7] + 1 in bits 8-15. This arrangement makes it possible to do R 
addressing in the same way for memory and non-memory microinstructions, and allows the 
24-bit address to be calculated with a 16-bit rather than a 24-bit add. Since a number of 
references will usually be done for each base register load, the calculation required to set up 
a base register should be insignificant. 

The processor calculates the virtual address in two steps. During cycleO of a memory 
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reference instruction, H1 is loaded from R[r] (which contains BP[8:23]), and H2 is loaded 
with the displacement. The displacement is taken from T if DF2 = 0, from F2 if DF2 = 1 (F2 is 
placed in bits 12-15, and the other 12 bits are zeroed). The R address used to access r is 
formed in a similar manner for memory and non-memory instructions, except that the RMOD 
bit of the instruction has another meaning (DF2) in the memory case, so it is not possible to 
select a base register pair using an indexed R address or with the stackpointer. 

During the second cycle, H1 + H2 is calculated in the ALU, and R[r or 1] is simultaneously 
accessed. The carry from the 16-bit addition is used to select the left or right byte of 
register R[r or 1] (BP[0:7] or BP[0:7] + 1) for delivery to the memory controller. Note that if 
RSEL[5] = 1 during a memory reference instruction, the odd base register will be used for 
both halves of the base pointer. This feature is useful when calculating the address to be 
used to refresh the memory, but is probably not useful otherwise. 

At the end of the instruction (at t2), the calculation of the virtual address will be complete, 
and the memory will be started (unless the instruction is aborted for some reason). Note that 
there is no way for a memory reference instruction to specify a write into R or T, so no part 
of a memory reference instruction overlaps the following instruction. 

If the instruction preceding a memory reference specifies a write of R or T, the data is held 
in H3P until the first non-memory instruction is executed, at which time H3P will be written 
into R or T (during cyclel). This introduces several programming restrictions which must be 
observed for proper operation: 

1) An R register specified as the source of data for a Pstore4 must be written before the instruction 
preceding the memory reference, since the processor may not be able to deposit the data in R before 
the memory controller needs it. This is also true of the source of data for a PStorei/2 if the PStore 
might be followed immediately by another memory reference, e.g. as the result of a task switch. 

2) At least one non-memory instruction must be executed between the loading of the odd R location of 
a base register pair and a memory reference instruction which uses the base pair, since the loading of 
R will be deferred until after the memory reference instruction, and bypassing does not work properly in 
this case. 

3) During cycleO of a memory reference instruction, R and T bypassing are done in the same way they 
are for a non-memory instruction. This means that if the even base register or T (the displacement) 
was loaded by the preceding instruction, the output of the ALU, rather than R or T, will be used to load 
H1 or H2. If the memory reference instruction is not aborted, these values are correct and all will go 
well, but if it is aborted, the output of the ALU will be the sum of the even base register and the 
displacement when the memory reference is finally executed. This quantity will be added to the base or 
displacement, yielding an incorrect virtual address. There is special logic in the processor which keeps 
H2 from being loaded in the cycleO following an aborted instruction, which eliminates the problem for 
the displacement from T. but there is no such iogic for H1. Accordingly, it is illegal to load the even 
r°s? recis + e r ; n t^ c : ^st r uctbn ;~v^ed ; ?:eK cee^"^ ? T»r^cry ;^e r ence unless it car be guaranteed 
that (1) the memory reference will not be aborted, or (2) the memory reference uses DF2 addressing 
with a displacement of zero (in this case, bypassing occurs, but the output of the ALU is the sum of 
the even base register and zero, which gives the correct result). 

4) If several memory references are done with no intervening non-memory instructions, the comments 
above apply to the base registers used by all the references, since register writes are pipelined across 
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ail the references (even references done in another task if a task switch occurs). 

5) If an R register or T is loaded in the instruction preceding a memory reference, it cannot be read in 
the instruction immediately following the reference, since the write will not be done until cyciel of the 
read instruction, but bypassing will be invoked during cycieO. The bypassed value is not the value 
written, but the result of the base register addition done by the memory reference. 

Usually, this is a disadvantage, but there is one circumstance where the results are beneficial. This is 
the 'bypass kludge'*. 

Assume that a base register is set up pointing to a structure, and it is necessary to reference the nth 
item of the structure, then to modify the base register to point to this item (examples are a base 
register holding a program counter during a JUMP instruction, or a base register used to chase down a 
pointer chain). The following code provides this function efficiently: 

T ♦• n; •displacement 

PFetchl(Base, dest]; "fetch the item 

Base ♦• T, gotof. +2, nocarry]; "update the low base register 

BaseHi - BaseHi + 400c + 1; "update the high base if 64k boundary crossed 



This code works because T was loaded immediately before the memory reference, and the write is 
piped across the reference. When the instruction Base^T is executed, bypassing is invoked, and the 
data written into Base is (Base + n). Also, the carry, flag holds the result of the Base + n addition, so a 
test for 64k boundary crossing can be done, and the high half of the base register updated if 
necessary. 

In summary, the following are illegal: 

Base «- x; 

BaseHi «• y; 

PFetchl [Base, dest]; "high base loaded in preceding instruction 

T <- Displacement; 

BaseHi «- y; 

Base «• x; 

PFetchl [Base, dest]; "low base loaded - displacement nonzero 

Source «• x; "this will occur after the PStorel is done... 

PStorel [Base, Source], return; "and the next instruction may be a memory reference in 

another task 

The following are legal: 

T «• displacement; 

PFetchl [Base, dest]: 

BaseHi «• y; 

Base ♦- x; 

PFetchl (Base, dest, 0]; "OF2 addressing with zero displacement 

Source «• x; 

PStorel (Base, source]; "ok to load source for PStorel /2 in preceding instruction 
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The virtual address in the DO contains only 22 significant bits due to the limited size of the 
map, although a full 24 bits are provided by the virtual address calculation. If bit 1 of the 
virtual address is nonzero (i.e. bits 1 or 9 of the base register), the memory controller will 
report a bounds fault when a memory reference is attempted using the base register. When 
the high base register is set up, bit should be ORed into bit 1 , and bit 8 should be ORed 
into bit 9. The FixVA short field descriptor is provided to facilitate this operation. 
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Figure 5.2.5 Address Calculation 
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5.3 R Interlocking 

The worst-case time between the execution of a memory reference microinstruction which 
uses R and the data transfer which it causes can be quite long if the effects of errors are 
accounted for. Between the time the reference is started and the time the memory controller 
takes or delivers the R data, the processor must not be allowed to read an R location for 
which a fetch is pending, nor write an R location for which a store is pending. So that 
programs need not always observe the worst case times, logic is provided which compares 
the R addresses in MC1 and MC2 with the R address generated by the processor, and aborts 
the current microinstruction if the processor attempts to reference an R location for which a 
memory access is pending. 

The precise conditions for aborting an instruction due to R conflicts are: 

Memlnsf and RA = PA and [(Ftype and ALUF#0) or (Stype and LR)], where RA is the R address 
generated by the processor during cycleO (the 'read address'), PA is the R address in MC1 or MC2 (the 
'pipe address'), and Ftype and Stype are the reference type in the pipe stage. Note that ALUF#0 
means 'processor is reading R\ Ftype operations are PFetch 1,2,4, ReadPipe, XMap, and Input. Stype 
operations are PStore1,2,4, and Output. 

The comparisons are done during cycleO for both MC1 and MC2 if the stage is active. At 
t1, the results are latched and used to abort the instruction during cyclel if there is a 
conflict. 

When a multiword is transferred to or from the memory, all R locations containing the item 
should be interlocked. Since there are only two address comparators, one for MC1 and one 
for MC2, R locations used for multiwords must be double- or quadword aligned for the 
interlock comparators to function. When the memory reference in MC1 or MC2 is a PFetch2 
or PStore2, the low bit of the addresses are not checked, so an instruction can access either 
word of the doubleword and cause interlock. Quadword references are similar - the low 
order two bits are omitted from the comparison. 

Note that the interlock comparators are not activated during memory reference instructions. 
This means that if a base register is fetched into R and then used in a memory reference 
instruction without being explicitly read first, the old version of the base register will be used 
if the base register has not been filled by the memory. This situation must be avoided by 
the programmer. 

The organization of the memory and the Mesa stack has two other potential problems: 

1) When a vaiue is pushed onto the stack, the stackpointer is not upuated until t2 of the instruction, 
a f ter the comparisons with the -jd cresses in MC 1 :nd MO? have been done if a PStore is pending 
from the stack, this couid cause the vaiue on tne stack to be overwritten before the memory has had a 
chance to store it. 

2) When a PFetch2 is pending to the stack, it is possible for the processor to read the R location 
which will eventually get the second word of a doubleword (the quantity being fetched to the top of the 
stack) without the interlock comparators recognizing the situation (since the R addresses may not be 
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doubieword aligned). 



To ensure that these situations cannot cause trouble, there are two additional conditions 
which cause a microinstruction to be aborted: 

A non-memory reference microinstruction is aborted if (1) it attempts to increment the stackpointer 
when a PStorel or PStore 2 is pending from the stack, or (2) if it attempts to decrement the 
stackpointer when a PFetch2 is pending to the stack. 

Note that this means that when the microcode does a doubieword fetch to the stack, it must 
pop the value (read it and decrement the stackpointer) reather than simply reading the value, 
or the check will be defeated. 

5.4 The Map 

Address translation in the DO is done by a 16K by 16 bit table lookup map located on the 
memory control card. The map receives bits 2-15 of the 24-bit virtual address from the ALU 
card, and produces the most significant 12 bits of the real address, plus four flag bits. 

The virtual address is time multiplexed in two cycles over the 7-bit StorA bus. The map row 
address is sent first, in the first MC1 cycle. During the second MC1 cycle, the map column 
address (which was latched at t2) is sent to the map. If the reference type requires a map 
cycle, the controller will have delivered RAS and CAS to the map chips, and the map data 
will become stable -170ns after t2 of the memory reference instruction. 

The Real Page address occupies bits 4-15 of a map entry, and is distributed as follows: 

Bits 4-6 are decoded into one of eight Card Select lines and sent to the storage cards. 

Bits 7 and 8 are decoded into one of four Block Select lines and sent to the storage cards. 

Bits 9-15 are the main Row Address, and are sent to the storage cards over the StorA bus under 
control ot the preRowAd signal generated by MC1. 

The remaining six address bits required by the storage cards are latched on the ALU card at 
t2 of the instruction which began the sequence. These bits are sent to the storage cards 
one cycle after the row address, also on the StorA bus. 

The flag bits in the map occupy bits 0-3 of a map entry. LogSngiErr (bit 0) and WriteProtect 
(bit 1) are written only when a map entry is loaded, but Dirty (bit 2) and Referenced (bit 3) 
will be set by MC1 during references of the appropriate type. These bits may also be written 
as part of map loading (by the XMap operation). The flag bits and the reference type 
determine whether a reference is permitted. A PROM in MCI examines the flag bits and the 
reference type, and produces a signal (MC1 Fault) which is tested by MC1 to determine if a 
reference is legal. The combination WriteProtect = Dirty « 1, Referenced * (which 
cannot normally occur) is used to indicate Vacant, i.e., no real page is assigned to this 
virtual page. 
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The map is read and written by the processor with the XMap operation. This operation uses 
a block of four R registers. It reads the data from the map entry corresponding to the virtual 
address supplied to the operation into the last three registers, then writes the first word of 
the block into the map entry. 
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Figure 5.5 ReadPipe R Register Format 



5.5 The Error Pipe 

A number of errors are possible during a memory reference. Errors detected by MC1 are: 

Page Faults (an attempt to access a page whose map entry has D = WP=1, Ref = 0). 

WriteProtect violations (an attempt to store into a page whose map entry has WP=1). 

Input Bus Parity Errors (also called H4Parity Errors): These can only occur on INPUT or lOStore 

operations. 

Bounds faults (Virtual address >22 bits). 

Errors detected by MC2 are: 

Double bit memory errors 

Single bit memory errors. Single errors are ignored if the operation is lOFetch (corrected data is sent 
tc the controller), and ,vi!! cr:!> ocz^ or-, a P c etc~ ; f the '..ogSng!E ; ' bi: ^ on ir. the map entry for the 
referenced page. 

When an error occurs, the memory controller finishes the reference if it can, sets the Fault 
flag, which will cause task 15 to run and deal with the error, and becomes idle. In ail cases, 
it is essential to recover the following information about the reference: 



The reference type 
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The number of the task which initiated the reference. 

The virtual address 

The real address and map flags 

The stage that detected the error (MCVMC2) 

If the error is a single or double memory error, the syndrome. 
If the reference is an INPUT or lOStore, the H4 parity error flag 

All of these items with the exception of the last two are contained in the error pipe memory. 
This memory is a 16 word by 8-bit RAM (although only 12 words are used) which is 
controlled by MC1. 

When MC1 is started, if the reference type is anything other than Refresh, Output, or 
ReadPipe (which cannot cause errors), a 'pipe slot' bit is assigned to the reference. This bit 
determines which half of the pipe RAM will be used to hold information about the reference, 
and is assigned by complementing the bit assigned to the preceding reference. During the 
time MC1 is processing the reference, the pipe RAM is written. 

If an error is detected by MC1 , Fault is set, and MC1 will not start another reference until the 
processor has had time to start the fault handling microcode. In addition to setting Fault, 
MC1 also sets MClErA or MClErB, depending on which pipe slot was used for the 
reference. 

If MC1 is error free, it starts MC2 if the reference is a Pfetch, lOfetch, Output, or Pstore1/2. 
The pipe slot bit is passed to MC2 so that if an error is detected, it can be reported by MC2. 
If MC2 detects an error, it sets MC2ErA or MC2ErB, depending on the pipe slot bit, and also 
loads the syndrome into one of two 8-bit registers, again depending on the pipe slot bit. An 
Output operation cannot cause an error in MC2. 

If an error occurs, task 15 can recover the information in the pipe RAM with a ReadPipe 
operation, which will dump the contents of the pipe RAM into six contiguous R registers. 
Figure 5.5 shows the format of a pipe entry. The data in the Pipe RAM is returned in the low 
byte of the six registers, while the high byte contains the flag bits that indicate the source of 
the error (these bits appear identically in all six words). If the function ResetMemErrs is 
executed as part of the ReadPipe instruction, the B pipe entry is delivered. If not, the A 
entry is delivered. ResetMemErrs clears the flag bits returned in the left byte of the 
ReadPipe, so the A pipe entry should be read by the fault handier first. 

The register containing the A and B syndromes may be read as an external R source. The A 
syndrome is in the left byte, the B syndrome is in the right byte. 

" ?•. Error Correction 

The DO memory is corrected over a 54-bit quadword. The check code generation fdurino 

stS' L y^ t r ^ a ^ erat f• ^ COrreCti0n " neC8SSary (durin 9 etches) are done word 
serially as the data are transported through the memory controller. 
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During PFetch operations, uncorrected data are transported into R on the assumption that 
there is no error. When the entire quadword has been transported, the syndrome is 
calculated, and if this assumption is correct, the processor is allowed to access the data. If 
correction is required, the data (which were saved in a buffer during the transport), are 
corrected on-the-fly, and sent to R a second time. 

During lOFetch operations, corrected data are sent to the device from the output of the 
buffer. If a double-bit error is detected during transport, the signal OFault is sent to the 
controller, so that it can terminate its operation if appropriate. 

Data errors generate processor faults as described in section 5.5. Single errors during I/O 
fetches are corrected, but no fault is generated, since this would degrade the bandwidth. 
Single errors detected during PFetches will generate a fault only if the LogSngiErr bit is on 
in the map entry for the page. Correction will always occur, however. 

The H-matrix for the Hamming code used in the DO is shown in figure 5.6. This code 
provides single error correction and double error detection, the decoding rule with which 
the bit in error is determined given the syndrome S[0:7] is as follows: 

1) If S[0:7] = 0, there is no error 

2) If the syndrome contains exactly one "1" bit, the associated check bit is in error. 

3) If the syndrome contains an odd number of "1 H bits and S[4:6] = 3, 5, 6, or 7, there is a single 
error. S[4:6] = 3 indicates an error in bits 0-15, S[4:6] = 5 indicates an error in bits 16-31, S[4:6] = 
6 indicates an error in bits 32-47, and S[4:6] = 7 indicates an error in bits 48-63. The bit within the 
word is given by S[3], S[2], S[1], S[0], treated as a 4 bit number. 

4) Otherwise, a double or multiple error exists. 
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Figure 5.6 Error Correction H-Matrix 
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5.7 Refresh 

The refresh operation is done by a task in the processor driven by a timer. A single 
execution of the Refresh operation refreshes four rows in both the map and main storage 
chips, so there need be only 32 Refresh operations done every 2ms (63usec/operation). 
The operation uses the 7-bit main column address register on the ALU card to supply the 
refresh address. This counter is loaded from bits 7-13 of the processor ALU output at t3 of 
the memory reference instruction, and is sent on the StorAO-6 lines two cycles after the MC1 
control bit PreRowAd is asserted. The column counter is normally incremented after it is 
used (to provide for page mode operations), so no special provisions are required to 
increment it. 

The refresh operation calculates a virtual address in the normal way (as do all memory 
reference instructions), but only bits 7-13 of the low order word are used. For this reason, 
the microcode should keep the refresh address in a single (odd) R register, increment the 
register by 16 when it is awakened (since the low order two bits are not used), then initiate 
the refresh operation with a displacement of 0. 

5.8 Memory Timing 

Figure 5.8 shows the timing of all memory reference operations. The time is in machine 
cycles, and to of the figure corresponds to t2 of the memory reference. This chart is a 
summary of Appendix B, and shows only the normal case for each reference. For the 
timings when errors occur, refer to the appendix. 
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5.9 Storage Card Organization 

The real address space of the DO is 1 megaword, divided into eight 128k regions. The 
backplane of the processor is wired such that the first 8 slots after the CPU can 
accommodate a memory card or an 10 device. Each slot corresponds to a fixed region (the 
first slot covers 0-1 28k, the second 128k to 256k and so forth). Currently, only 96k storage 
cards exist. Provision is made for a future 128k storage card when RAM density is increased 
beyond the current 16k bits per chip limit. Since the slot covers the entire 128k region, and 
a card can have as little as 64k of memory, there are holes in the real address space if 64k 
or 96k cards are used. In fact, since an IO device can be plugged into a memory slot, the 
holes can be as large as 128k. The processor determines the configuration of real memory 
at boot time and provides the software with a map showing the location of the holes. The 
system software must accommodate malfunctioning sections of real memory, so minimal 
extra work will be needed to cope with the holes. This scheme introduces the following 
configuration rule: Storage Cards must be plugged into the first 8 slots (this is enforced by 
keying the cards physically). I/O cards may be plugged into any slot, but there may be no 
gaps between any cards. 

The 96k storage card is shown in block diagram form in figure 5.9 The card is divided into 
three 16k x 32 banks (plus 4 Error Correction bits per bank). For any memory cycle to the 
card, two of the three banks will be started, thus memory is cycled in 64 bit quadwords. 
Consider the 128k region of the address space covered by the card to be composed of four 
32k blocks (blocks correspond to 32k sections of the real address space; banks correspond 
to physical arrays of RAM chips on the storage card). Block 0, when addressed, will cause 
banks and 1 to be cycled. A cycle to block 1 will use banks and 2, while block 2 will use 
banks 1 and 2. Block 3 is the 32k hole. 

For each block, one of the two banks contains the even doubieword involved in the memory 
cycle while the other contains the odd doubieword. Bank contains even double words for 
blocks and 1. Bank 2 contains odd doubiewords for blocks 1 and 2. Bank 1 contains odd 
doubiewords for block 0, but contains even doubiewords for block 2. The chart in figure 5.9 
shows all of this in a readable form. The basic idea is that Bank always contains even 
doubiewords, bank 2 always contains odd doubiewords, and bank 1 contains both even and 
odd doubiewords. 

The piped control section of the memory system allows the storage card to be considered as 
three independent pieces, Input Transport, Memory Cycle, and Output Transport. Input 
transport data arriving from the processor for a write cycle on the 16 bit bus is buffered and 
held in registers which are strobed in the sequence: low bits of even DW, high bits of even 
DW low bits of odd DW, high bits of odd DW. Since bank always gets even DWs. its input 
registers are clocked in the first two cycles of every transport. Similarly, the input registers 
for oanK 2 are clocked on the 3rd and 4th cycles. Since the real address bits (and therefore 
the card and block number) are not available until mapping is finished (which is after the first 
two cycles of transport), bank 1 cannot determine whether to load even DWs or Odd DWs 
until the 3rd cycle. Therefore it loads ail even DWs, and then loads the odd DW on top of it 
if block was the addressed block (ie. if bank 1 contains odd DW's for the addressed 
region). 
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ErrorCorrection bits are transported with the 4th data word. Bank always latches the 
upper 4 bits, bank 2 always latches the lower 4 bits. Bank 1 has two-way input multiplexing 
which selects between the upper and the lower bits as a function of BlockSelO. If BlockSelO 
is asserted, bank 1 latches the lower bits. Otherwise, it latches the upper bits. 

The memory control in the processor decodes the top 3 bits of the real address from the 
map to determine which of the 8 cards will be run. The decoder outputs are wired to the 
corresponding slot, so that no on-card decoding is needed on the storage card. The block 
bits (real address bits 4 and 5) are also decoded, but every card gets all four SelectBank 
signals SB0-SB3 (note that the 96k card does not use SB3, and the 64k card uses neither 
SB2 or SB3). The card ands the SelCard signal with the SB signals to produce BlockSelO, 
BlockSell and BlockSel2. Two of the three BlockSel signals are ored together and nanofed 
with buffered RAS to produce BankRAS' signals for each of the 3 banks. A similar circuit 
creates BankCAS' and BankWrite' for three banks. For refresh, the processor enables all 
CardSel lines as well as all three SB lines, so all chips get the refresh cycle. 

While A1-A6 for the chips need only buffering for fan-out, AO needs additional gating to 
select between the halves of the chip used for each of the two blocks for which the bank 
contains data. During RAS, the backplane AO signal is sent to all chips. During CAS, one of 
the two banks gets a 1 in AO, while the other gets a 0. The memory control card will force 
the backplane AO to a during CAS and provide the CASA signal (an early version of CAS) 
to enable this logic. 

For a read cycle, the Card/Bank selection circuitry and the addressing logic works the same 
way as it does for a write. When the data comes out of the RAM chips, the 96 output bits 
are multiplexed down to the 64 bits that actually contribute data and are latched. The 
multiplexing depends on the fact that the even DW can only come from bank or bank 1, 
while the odd DW can only come from bank 1 or bank 2, so only two way multiplexing is 
necessary. 

Once these bits are stored in the output register, MC2 controls the transfer of data to the 
processor. The 64 bits are muxed to 16 by a set of 4 way multiplexers with tri-state outputs. 
The enable for the outputs is a latched version of CardSel. MC2 controls the select inputs to 
the multiplexor sending the data into the processor in the order it was transported during a 
store. The EC bits have two way muxing similar to the data bits. All 8 bits are transported 
with the first word of data going in to the processor. 

All input signals to the card are buffered to present 1 load to the bus (exceptions: SelCard 
has loading of 5, but is private to each card, clkOutputReg has a loading of 2. It can be 
driven with a high current driver and so should not cause problems). The drivers for the 
; iGS RAMs are fanned out to 16 emus usiny an S series gate (Si2^4 cnips per bank/2 
^rivers = 18 chips/criver) with a se-.^s damping resistor co minimize undershoot. Data 
outputs from the RAM chips drive two loads (two inputs of 25S09s). The only outputs from 
the card are the output data bits (which are tri-state outputs of S253s) and the EC output 
bits (8T96s). 
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6.0 Input-Output 

The preceding section discussed the memory and I/O operations available to a 
microprogram. This section will discuss the interface between the processor/memory 
system and I/O controllers. 

I/O controllers in the DO are intimately associated with microcoded tasks in the processor. 
When the controller requires service (typically to request or deliver data from a device), it 
generates a wakeup request, which will (eventually) cause its associated task in the 
processor to run and provide the requested service. All memory requests are made by the 
processor, although the actual transfer of data will often occur directly between the memory 
and the controller. The processor can exchange status information or data with a controller 
using INPUT and OUTPUT instructions. There are also two lines, shared by all controllers, 
which allow a single bit of status to be transferred between the microprogram and the 
controller without incurring the delays introduced by the memory system when INPUT and 
OUTPUT operations are done. 

The interface between a controller and the processor/ memory consists of a fixed set of 
signals which use well-defined signalling protocols. Use of some of the signals is optional, 
but all controllers must provide a minimum set of capabilities. 

Subsequent sections will discuss the interface signals, the way in which controller 
addressing is done, how wakeup requests are made, the sequence of events in data 
transfers, and the special signals in the interface. 

Appendix C shows the logic required to implement the minimum set of functions required in 
all controllers. 

6.1 Interface Signals 

Table 6.1 lists all signals available to I/O controllers. These signals are grouped into six 
categories based on their function. Subsequent sections describe their functions in detail. 
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Table 6.1 



Signal Name 



Number of 

Lines 



input or Output/ 
Driver/ Rev r type 



Use 



Signals that establish the controller address: 

SPIn* 1 IS 

SPOut* 1 OS 

SPCIock 1 IS 



Controller address in 
Controller address out 
Clock for controller address 



Signals associated with wakeup request generation: 



PhaselNext 1 


1 


IS 


Wakeup state machine control 


WakePr 


1 


OW.IS 


Wakeup Request 


WakeP2' 


1 


OW,lS 


Wakeup Request 


WakeP3' 


1 


OWJS 


Wakeup Request 


Data input signals 


(processor/memory <-« 


• controller): 


IAddr[0:7] 


8 


IP 


Input Address 


IValid' 


1 


IP 


Input Address Valid 


IData[0:l5] 


16 


OT 


Input Data 


I0ata(l6] 


1 


OT 


Input Data Parity 


Data output 


signals 


(processor/memory - 


-> controller): 


AdvancePipe 1 


1 - 


IP 


Address pipeline 


MC2StartXPort 1 


IP 


Address pipeline 


OValid* 


1 


IP 


Indicates output data is valid 


O0ata(0:l5] 


16 


IP 


Output Data 


OData[i6] 


1 


IP 


Output Data Parity 


OFaulf 


1 


IP 


Output Fault 



Single-bit communication path signals: 

lOAttn' 1 OW 

lOStrobe 1 IP 

Clocks and processor status signals: 

CTask[0:3] 4 IP 

RUN 1 IP 

EdgeClockFeed' 1 IS 

RamCiockFeed' 1 IS 



Attention signal to processor 
Strobe from processor 



Task currently running on processor 
Low if processor not ready 
Clock 
Clock 



1) Although signals are named relative to the processor (i.e. Output means data to a controller), these signals 

are specified relative to the controller as follows: 

IP: Each board will receive this input line with one PNP input load 

IS: Each board will receive this input line with one Schottky TTL load 

OS: Each board will drive this line with one Schottky TTL output (totem-pole) 

GT: Each board will drive this cutout line with one Schottky tri-state output 

OW': Eacn board will drive this iine wun one SN74S38 Wire-or driver 



All signals in the machine begin to change on the rising edge of EdgeClock 5 (which is 
delayed from the backplane signal EdgeClockFeed' by two S levels). Signals generated in 
the processor will become stable no later that -30ns after EdgeClock' rises, and signals 
generated by controllers should be stable 30ns before the clock rises. EdgeClockFeed' on 
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the backpanel is low for 25% of a cycle, RamClockFeecT is low for 50% of a cycle, and the 
rising edges of these signals are conicident (within skew limits). 

6.2 Controller Addressing 

Each controller in a DO system is associated with a task in the processor. A single controller 
may have up to sixteen internal registers which may be read or written by the 
processor/memory. The functional assignment of the registers within a controller is 
unspecified with the exception of INPUT register 0, which will return a 16-bit identification 
number unique to the board type when it is read. When the processor executes a memory 
or I/O operation directed to a particular controller, it specifies an eight-bit I/O Address. The 
most significant four bits of this address are the task number, the low order four bits select 
one of the sixteen registers within the controller. Since there will be many types of 
controller, it is not possible to build the task number into each controller when it is designed, 
nor is it desirable to establish the task number with switches when the controller is installed. 
Instead, the task number is assigned dynamically by the processor using the SRIn', SROut\ 
and SRCIock lines. 

Each controller will provide a four-bit CAddr shift register, which holds the task number 
associated with the controller. The input of this register is SRIn\ the output is SROut', and 
the clock is connected to SRCIock (the register clocks on the positive-going clock 
transition). SROut' from one card slot is wired to SRIn' on the next card, and the SRCIock 
lines are connected together. Storage cards jumper SRIn' to SROut 5 , and SRIn' for the slot 
closest to the processor (slot 5) is connected to H2.15. 

The processor can set an address into each controller by serially placing a bit pattern in 
H2.15 and executing the function GenSRCIock, which sends one clock to all the shift 
registers. For a 12-slot system, 48 clocks are required to initialize all possible controllers. 
The backplane is built so that slots 5-12 can accept either storage cards or I/O controllers, 
slots 13-16 can accept only I/O controllers. Subject to this limitation, storage cards and 
controllers can be mixed in any order, as long as there are no gaps between cards. 

At bootstrap time, the microcode will load a fixed initialization pattern (which makes all 
controller addresses unique) into the register, then read register in each device to 
determine the type of controller (if one is present). Load devices may be located in this 
manner, and the processor may then change the assignment of controllers to correspond to 
the proper task priority arrangements for the particular microcode and peripheral 
configuration present. 

5.3 Task Wakeup Requests 

When an IO device needs service from its associated task in the processor, it generates a 
wakeup request. In each controller, the CAddr' register holds the complement of the number 
of the task associated with the controller. The number of the task is also its priority. A 
wakeup request sequence requires two distinct phases. During the first phase (phase 1), 
each controller which needs service ORs an encoded version of the two most significant bits 
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of its task number onto the WakePl , WakeP2, and WakeP3 lines as follows (the WakeP lines 
are low true on the backplane): 

Task Number CAddr(0:3] WakePl WakeP2 WakeP3 

0-3 OOxx 000 

4-7 1 x x 1 

8-11 1 x x 1 

12-15 1 1 x x 1 

At the end of phase 1 , the processor will encode the WakeP lines into a two-bit number 
corresponding the the most significant bits of the highest priority requesting task: 

PT0 * WakeP2 OR WakeP3 

PT1 * WakeP3 or (WakePl and not WakeP2) 

At the same time, all controllers will examine the WakeP lines, and those which see lines 
corresponding to requests made by higher priority controllers will not participate in the 
second phase of the request sequence. 

During the second phase of a request sequence (phase 2), the controlers which are still 
participating will OR a similarly encoded version of the least significant two bits of their task 
number onto the WakeP lines: 

CAddr[0:3] WakePl WakeP2 WakeP3 



1 
10 
1 



The processor encodes these lines using the same process as in the first phase. The 
resulting two bits and the two bits which were saved from the first phase are latched in the 
processor. These bits are the task number of the highest priority requesting task (HTask). 

The timing of the wakeup logic is shown in figure 6.2 The signal Phase"! Next' is supplied to 
ail controllers by the processor to synchronize the processor and controller logic. 
PhaselNext will always be exactly one cycle in length (although since EdgeClock may be 
withheld by the branch logic, the duration of a cycle is sometimes doubled). Request phase 
1 occupies the cycle immediately following PhaselNext, and request phase 2 occupies all 
subsequent cycles unit! the next occurrence of PhaselNext Normally, phase 2 will also be 
one cycle in length, but if processor cycies are suspended. PhaselNext will be deferred, and 
phase 2 will be extended. Controllers must present valid data on the WakeP lines even if 
suspension occurs. Note that the delay between the time that a controller asserts or 
removes the wakeup request and the time the processor responds by running the task is a 
minimum of three instruction times. Designs for controllers and their associated microcode 
must take this latency into account. 



Task Number 


CAddrl 


4,8,12 


x x 


1,5,9,13 


x x 1 


2,6,10,14 


x x 1 


3,7,11 


X x 1 1 
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Figure 6.2 Wakeup Latency 



6.3 input and Output Operations 

Data is read from device controllers with INPUT or lOStore operations. From the point of 
view of the controller, these operations are indistinguishable, since they result in the same 
sequence of signals. 

An input operation is started when the processor starts MC1 and places the I/O address on 
the lAddr lines. Some number of cycles later (the number depends on the operation), the 
memory controller will assert I Valid. The controller that recognized the address will return 
data in the cycle following the one in which IValid is asserted. The parity bit (IData[16]) must 
be returned in the same cycle as the data. 

Output is more complex, since transport of data to the controllers is controlled by MC2, not 
MC1. An output operation begins in the same way as an input, with the loading of lAddr. 
Some number of cycles later, MC1 has completed its work and MC2 is started. At this time, 
the processor issues AdvancePipe, and may change lAddr. The controller is expected to 
use AdvancePipe to latch the data from lAddr in an internal register which is essentially a 
part of MC2. 



Since the transport of data from MC2 can overlap the time at which MC2 is started for the 
next reference (probably for a different address), a third stage in the address pipeline is 
required. The memory controller issues the signal MC2StartXport just prior to the time it will 
begin :c deliver data tc the ccr.:rcll3r. and tne controller is expected to use this signal to 
latch tne output of the register c:cc\ed b> Advance D ipo in yet another register. This finai 
register is the one that the controller compares with CAddr to determine if it is the 
destination for an output operation. When the memory finally has data to deliver, it asserts 
the signal OValid. The controller should use OValid to latch the OData lines (OValid should, 
of course, be used to qualify EdgeClock). If the memory delivers OFault in the same cycle 
as the one in which OValid is delivered, it indicates that a double error has been detected. 
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The controller may use this signal in whatever way it wants. The memory will deliver the odd 
parity bit OData[16] in the cycle following the data. Controllers may choose to ignore the 
parity bit if data integrity is not crucial (e.g. data for a display). 



6.6 I/O Attention, I/O Strobe, RUN 

In many cases, the microcode for an IO device controller will use a tight loop to transfer data 
to or from a controller. Some devices may need to inform the processor of exceptional 
conditions which should terminate or modify such a loop. To provide this capability, the 
processor delivers the number of the task which has control of the processor on the 
CTask[0:3] lines. IO device controllers may receive these lines and return the (wire-ored) 
signal lOAttn 1 to the processor. At t1 of each microinstruction, lOAttn' is latched in the 
processor, and a branch condition is provided to test its value. Each board will drive the 
lOAttn' line with a single wire-or driver (SN74S38). 

Note: Since the time for CTask(0:3] to reach the controller and be returned to the processor as lOAttn' is longer 
than one cycle, microprograms should not test the value of lOAttn in any instruction following a RETURN, since 
the RETURN may cause a task switch. 

The lOStrobe signal allows the processor to send a single bit of information to the controller 
without incurring the delay associated with the OUTPUT operation. The function lOStrobe 
makes this line true for one cycle. Each controller can AND this line with a signal that 
indicates that its associated task is running (CTask « CAddr), and use the resulting signal 
for any purpose it wishes. 

A reset signal is distributed to all IO controllers. This signal, RUN, is cleared during a 
bootstrap operation, and if the +5V supply drops below approximately 4.7V. In particular, 
this line should terminate writing on magnetic media devices. All controllers should reset 
and quiesce themselves when this line is dropped, and also when an OUTPUT operation with 
data = is directed to the devices' s control register (the microcode will reset the IO system 
by doing for i = o to 265 do outputp,o]) After RUN becomes high, device controllers should 
refrain from requesting wakeups until explicitly enabled by their microcode. 

Device controllers may implement other task-specific reset operations via OUTPUT 
instructions if they need them. 
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7.0 User Terminals and Controllers 

7.1 Terminal to Controller Interface 

So that a number of different controller and terminal types may be freely interconnected in 
DO-based systems, a common interface between terminals and controllers has been defined. 
This interface assumes that a terminal contains a raster-scanned bitmap display and one or 
more low bandwidth input devices (keyboard, pointing device, etc.). The controller transmits 
digital video and sync to the terminal over six pairs of a seven-pair cable. The input data is 
transmitted to the controller serially over the seventh pair (the "backchannel"). Video and 
control (sync) are time-multiplexed, and four bits are transmitted in parallel to reduce the 
bandwidth required on the cable. 

While the description in the following sections assumes a display having one bit per pixel, 
the basic signalling mechanism may be extended to support gray-level or color displays. 

7.1.1 Cables and Connectors 

The interface cable is Belden #9507 or equivalent. This cable consists of seven twisted 
pairs of #24 AWG stranded, vinyl insulated wire, surrounded by a foil shield with a stranded 
drain wire and an overall vinyl jacket. The outside diameter of the cable is .290". 

Six of the seven pairs are laid in a spiral around the seventh pair (the red/black pair). As a 
result, the electrical length of the red/black pair is much less than that of the remaining 
pairs. Since the interface depends on having minimum skew between the six pairs used for 
the high speed section, the red/black pair is used for the backchannel. 

The interface connector is a 15 pin Cannon "D" series or equivalent unit (several sources 
exist). The controller contains a male connector, the terminal contains a female connector. 

7.1.2 Drivers and Receivers 

Figure 7.1.1 shows the drivers and receivers used in the interface. ECL 10K differential 
drivers with 220 ohm pulldown resistors to -5.2v are used to drive each pair. The receiving 
end of each pair is terminated in 100 ohms, and differential ECL receivers are used to 
recover the data. 

7.1.3 Video and Control Channel 

rius section of ihe interface uses Six pai;s \r\ the caoie. Four bits of data are transmitted in 
parallel from the controller to the terminal, accompanied by two clock signals. The four data 
bits are interpreted as video or control by the terminal, depending on the phase of the clock. 
Figure 7.1.3 shows the timing relationships in the interface. The controller places data on 
the data lines on the failing edge on ClkA. The data are sampled by the terminal on the 
rising edge of ClkA. If ClkB = 1 at this time, the nibble is interpreted as four bits of video. 
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If ClkB = 0, the nibble is interpreted as syne and control information. ClkA and C!kB are 
transmitted in quadrature so that the terminal can reconstitute a clock at the video bit rate. 

When video data is serialized by the terminal, bit is transmitted first, bit 3 is transmitted 
last. A logic corresponds to a blanked display. 

[Note: OSD display specifications refer to bit as the "least significant bit" of a nibble, and 
state that this bit is transmitted first. In DO memory, bitmaps are stored such that the most 
significant bit is transmitted first, but since the DO convention is that bit is the msb, the bit 
numbers in OSD specifications are the same as DO bit numbering.] 

When a nibble is interpreted as control information, bit 2 is reserved for horizontal sync, bit 3 
is reserved for vertical sync. The interpretation of bits and 1 is not defined; different types 
of terminal may use them for different purposes. 

7.1.4 Backchannel 

Data from low bandwidth input devices at the terminal are transmitted serially over this line. 
The data are clocked by the terminal on the falling edge of the horizontal sync pulse, and 
will be sampled by the controller during the subsequent scan line. Data are transmitted in a 
frame composed of a single "start" bit (a logic one), followed by a number of data bits. A 
frame is transmitted when any input signal at the terminal changes state. The idle state of 
the line is logic zero. 

Since different types of terminals may have differing amounts of information to transmit, the 
format of a frame is not defined. The controller microcode must provide whatever 
capabilities are required by a particular terminal. 
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Figure 7.1.1 Terminal Interface Drivers, Cable, and Receivers 



Pixel Rate Clock 



One Nibble 

K — One Pixel 




I'.ockA 



ClockB 



Controller will 
present data 



A 



A 



Terminal will 
sample data 



t_ 



i 



/\ 



i 



r 



\* ClockB is low when Cock a nses. the terminal will interpret 
the nibble as 4 control bits, if clockB is high, theterminai 
will Interpret the nibble as video data. 



Figure 7.1.3 Terminal Interface Timing 



Section 7: User Terminals and Controllers 



76 



7.2 UTVFC (User Terminal Variable Format Controller) 
7.2.1 Introduction 

The UTVFC occupies a single DO board, and supports up to four user terminals utilizing the 
interface and protocol described in section 7.1. The major subsections of the board are 
shown in figure 7.2.1. The UTVFC provides horizontal sync for all channels, data buffering 
for up to 1024 bits per scan line for each channel, a 32 x 32 bit hardware cursor for two of 
the channels, receivers for the backchannel associated with each terminal, and the logic 
necessary to interface the DO I/O system. The video bit rate, horizontal line rate, number of 
words per scan line and vertical field rate for all four channels must be identical. The bit 
rate is set by a crystal oscillator, the line rate is determined by the horizontal control RAM, 
which must be initialized by the processor, and the vertical field rate is determined by the 
controller microcode, which must count scan lines. The microcode is also responsible for 
accumulating the serial backchannel message. 

The UTVFC also contains provisions for single-stepping the video clock, and reading a 
number of internal signals. 
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7.2.2 Output Registers 

Figure 7.2.2 shows the assignment of output register addresses in the UTVFC. Eleven of the 
sixteen possible registers available to a controller are used. The function of each register is 
discussed briefly here, and more fully in following sections. These registers cannot be read 
directly, but most can be read indirectly via the diagnostic interface. 

Register is the control register. The most significant byte of the control register holds the 
two unassigned bits that are sent to each terminal as part of a control nibble. Bits 8, 14, and 
15 control the clock generator and enable controller wakeup requests. Bits 9 and 10 control 
the polarity of the video for channels and 1, and bits 11-13 control terminal blanking during 
vertical retrace and the generation of vertical sync. 

Register 1 is the data buffer starting address register. This register must be initialized by the 
microcode with 64d-Nwrds (the number of memory words per scan line) as a function of the 
terminal type. Bits and 1 should be 11 during normal operation; they are provided for 
diagnostic control and to initialize the horizontal control RAM. 

Register 2 is the horizontal control RAM location addressed by AAR[0:7j. The horizontal 
control RAM is loaded only during controller initialization. 

Doing an OUTPUT to register 3 does not cause data to be transferred from the DO, but loads 
IAR from START. 

Registers 4 and 5 are the cursor control registers for channels and 1 . These registers are 
loaded by the microcode during every scan line preceding a line in which the cursor is 
visible. 

Registers 6 and 7 are the cursor memory locations addressed by COAddr and ClAddr. It is 
only necessary to load the cursor memory when the cursor bitmap is changed. 

Registers 10b through 14b are the data buffers for the four display channels. These buffers 
are loaded with data to be serialized as video. 
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7.2.3 Timing and Sync Generation 

The basic frequency source in the UTVFC is a crystal oscillator which operates at the video 
bit rate. This frequency is divided by four in a two-bit Gray code counter to form the signals 
ClkA, ClkB, and NCIk (nibble clock). Most register transfers within that portion of the UTVFC 
synchronized to the video rate occur on the fall of NCIk. The Gray counter sequence is: 



ClkA 


ClkB 


NCIk 














1 





1 


1 






1 1 

Note that ClkA and ClkB are in quadrature, and that NCIk falls when ClkA rises, which 
causes the data to the terminal to change in accordance with the terminal protocol. 
Internally, ClkB runs continuously, but the signal DropClockB will cause it to be suppressed 
at the terminal cable drivers. 

The DO microprogram can control the clock generator using the AllowWU, IncNC, and ClrNC 
bits of the control register. If AllowWU is true, the crystal oscillator is enabled. If AllowWU 
is false, the oscillator is disabled. While the oscillator is disabled, an OUTPUT to the control 
register with ClrNC true resets the Gray counter, and OUTPUT with IncNC true increments 
the counter. Four OUTPUTS generate one Nclk. 

The logic that generates the synchronization signals and controls transmission of data to the 
terminal is shown in figure 7.2.3. The horizontal control RAM is the principal source of 
control signals. This RAM is addressed by the Active Address Register (AAR), which also 
addresses the data buffer whose contents are currently being sent to the terminals. Each 
scan line is divided into two segments by the signal ControlPhase. When ControlPhase is 
false, data are sent to the terminals. As each nibble is transmitted, AAR is incremented, 
which accesses the next address in the horizontal control RAM. During this segment of the 
scan line, the signals HS and Switch are forced to zero by the multiplexer on the input of the 
horizontal control register. Only the signals ML (associated with vertical sync generation) 
and SetCPhase are determined by the RAM contents. 

When a RAM location with SetCPhase = 1 is accessed, the ControlPhase flip-flop is set. 
ControlPhase forces the data being sent to the terminal to zero (blanking the display), and 
also switches the horizontal control register input multiplexer so that the signals HS and 
Switch are determined by the contents of the RAM. AAR continues to increment until a RAM 
location with Switch = 1 is accessed. When Switch occurs, ControlPhase is cleared. 
AAR[0:7] is loaded from 3tart[u:5],.0, and the cycle repeats. At switch time, the 
synchronized control register is leaded from the control reg;ste; In preparation for the next 
scan line. Switch also complements the Even/Odd Line flip flop, which causes the roles of 
the inactive and active data buffers to be reversed. 

During ControlPhase, a horizontal sync signal will be sent to the terminal. The width of the 
sync pulse and its relationship to the blanking interval are determined by the contents of the 
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horizontal control RAM. Figure 7.2.4 shows the timing of events in the vicinity of a horizontal 
sync pulse in detail. The signal (HS or VS) sets the SendControl flip flop which causes 
DropCIockB to be set one nibble time later. DropClockB causes the terminal to interpret the 
data lines as control information. SendControl is used in the data section of the UTVFC to 
gate HS and VS to the data lines (the bits in the most significant byte of the control register 
are also sent). When (HS or VS) becomes false, SendControl is extended for one extra 
nibble time to allow the control register in the terminal to be cleared. 

Generation of vertical sync is the responsibility of the UTVFC microprogram. Both interlaced 
and non-interlaced displays may be driven by the UTVFC. The microcode must change the 
PPVS bit in the control register during the scan line preceding the one in which VS is to 
change. The state of the OddField bit determines whether VS will change on the falling 
edge of HS (OddField = 1), or on the falling edge of ML (OddField = 0). 

The UTVFC requests a wakeup at the beginning of every horizontal line (at the fall of 
SWITCH). The wakeup request remains set until explicitly cleared by the lOStrobe function, 
except that a wakeup request will not be issued if the UTVFC's task is running. The 
AllowWU bit in the control register unconditionally disables wakeup requests. 
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7.2.4 Data Buffering 

The UTVFC contains two data buffers, each of which holds a full scan line for four terminals. 
One buffer is loaded by the DO while the other is being transmitted to the displays. The 
signal Switch, which is generated by the control logic at the end of each scan line, ping- 
pongs the buffers. Figure 7.2.5 shows the data buffers and their interconnection. 

There are two address registers for the data buffers. IAR, the Inactive Address Register, 
addresses the buffer currently being loaded by the DO. AAR, the Active Address Register, 
addresses the buffer being read to the terminals. AAR also addresses the horizontal control 
RAM. 

IAR is a six-bit register. It supplies the most significant bits of the inactive buffer address; 
the low two bits are functions of Oaddr.6 and Oaddr.7. IAR is incremented by one each time 
the DO delivers a word to the inactive data buffer. IAR is loaded from the register START 
when IAR = 63d and the DO delivers a word to the buffer. START should contain 64d minus 
the number of words to be displayed on a scan line, so if IAR initially contains the value in 
START and the DO delivers (64d-START) words during a scan line, IAR will end up with its 
initial value. This makes it unnecessary for the DO to modify IAR unless START is changed. 
A bit in START (ForcelARLoad') forces IAR to be loaded from START each time the DO 
delivers a word to the buffer. This is provided for testing and initialization. 

AAR is an eight bit register. It is incremented by NCIk. AAR is loaded with 4*START by 
Switch. There is a bit in START (ForceAARLoad) which loads AAR on every NCIk. This is 
provided for testing, and to initialize the Horizontal Control RAM. 

During each scan line, the processor delivers the data for the next scan line for the first 
terminal, then delivers a full scan line for the second terminal, and so forth. When the data 
are being transmitted to the terminals, the first nibble for all four terminals is read, then the 
second nibble, and so on. To accomplish this, each four-bit section of both buffers is 
independently addressable, and there is logic at the input and at the output of the buffers to 
shift the data appropriately. 

When the DO delivers a 16-bit word to the buffer, the data are cycled so that the most 
significant nibble for terminal n is placed in buffer n. In addition, the low order two bit§ of 
the buffer address are set as a function of the terminal number so that nibble n of the data 
for all terminals is stored in buffer location n. The buffer address is then incremented by 4 
(by incrementing IAR by 1). This operation results in the data being located in the buffer as 
shown in figure 7.2.6. 

When data are removed from the buffer, the words are accessed sequentially (since each 
word contains one nibble for each of the four terminals), but the data must be cycled to 
remove the cycle introduced when the buffer was loaded. This is done by the output shifter. 
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Control information is multiplexed with the video data between the first and second rank of 
the output shifter. The first rank of the shifter is disabled by SendControl, and the terminal 
control bits, HS, and VS are tri-stated onto these lines. The second rank of the shifter is 
composed of multiplexer-latches that drive the data line level converters for channels 2 and 
3 directly. Channels and 1 have hardware to mix the cursor with the video data between 
the shifter register and the line drivers. 

Channels and 1 also have logic to control the polarity of the background video. If the 
BckGndO/1 bit in the control register is zero, the associated channel will display white for 
zero bits in memory. The cursor is ORed with the video data before the background polarity 
is selected, so ones in the cursor memory always correspond to a polarity opposite of that of 
the background. For channels 2 and 3, zeros in memory correspond to a blanked display. 
The PPBIank bit in the control register causes the terminal to be blanked by disabling the 
line drivers (but the line drivers are enabled when control is transmitted). Because of the 
delay introduced by cursor mixing, the data and clocks for channels and 1 have an extra 
level of latching, which delays them by one nibble relative to channels 2 and 3. This is only 
important for terminals (e.g. color terminals) that use more than one channel to drive a 
single display. 
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7.2.5 Cursor 

Channels and 1 of the UTVFC contain logic to generate 32x32 bit cursors (see figure 
7.2.7). A 256x4 RAM holds the cursor video pattern for each channel. This RAM is 
addressed by CxAddr[0:7]. Bits 0-4 of this register select one of 32 eight-nibble cursor 
segments to be displayed on a particular scan line. In the scan line preceding the one in 
which cursor segment S is to be displayed, the microcode will load the cursor control 
register with S in bits 0-4, with a one in bit 5 to enable the cursor logic, and with the 
negative of the x coordinate of the leftmost bit of the cursor in bits 6-15. During the next 
control phase, this quantity is loaded into the cursor x position counter. During the 
subsequent scan line, the x position counter is incremented by NCIk until its most significant 
five bits are zero, at which time CxShift becomes true. During the next eight nibble times, 
the cursor RAM outputs are enabled, and the eight nibbles of cursor segment S are loaded 
into the output register (at all other times, the cursor RAM outputs are forced to zero). The 
final shift required to place the cursor on the scan line with a precision of one bit is provided 
by the cursor shifter, controlled by the low two bits of the x holding register. Up to three bits 
of a given nibble may be shifted so that they must be merged with the following nibble; 
these bits are recirculated through the output register. The cursor video (CxDO-3) is ORed 
with the main video as described in figure 7.2.4. 

The cursor memory must be loaded during vertical retrace, since the value in the x position 
counter used to address the cursor RAM can only be set if PBIank = 1. During this time, the 
x position counter is loaded from the x holding register, so the microprogram can load an 
address into CxAddr[0:7], then write the data for that location into the cursor RAM (a total of 
512 OUTPUT operations are required to load the RAM with the full 32x32 cursor). 
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7.2.6 Backchannel 

The state of the backchannel message bit from the terminal is provided on the lOAttn line. 
lOAttn will be true if the message bit is a logical one. The terminal that is selected to deliver 
its message is determined by IAddr.6-7. The intent is that the microcode will send the first 
block of data to a terminal with a memory operation (which will set IAddr.6-7 to the terminal 
number), then branch on lOAttn before doing a task switch or other memory reference. 
Since lOAttn must be sampled every scan line, this means that the microcode may have to 
do an innocuous memory operation to set the terminal number if it has no data to deliver. 

7.2.7 Controller identification and Diagnostic Input 

The UTVFC provides only one Input register. This register is transmitted when any of the 
sixteen registers available to the UTVFC's task are accessed. The format of the register is 
shown in figure 7.2.8. The most significant byte of the register contains 2, the UTVFC's 
unique ID number. Bits 8 through 12 are determined by wiring on the platform containing 
the crystal oscillator, and indicate the frequency of the bitclock. Bits 13-14 are 10, and bit 
15 is the Test Bit. 

The Test Bit is the output of a forty-bit shift register whose inputs are connected to a 
number of internal signals in the controller (refer to the logic diagrams). When an INPUT is 
done from a register with address >3 (mod 16) these bits are loaded into the shift register. 
When an INPUT is done with address <4, the register is shifted. The intent is that a (Mesa) 
program can be written that controls the UTVFC clock and checks most of the internal logic 
of the UTVFC via this path. 
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Figure 7.2.8 Input Register Format 
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8-0 Rigid Disk ControUer 

8.1 Introduction 

The Rigid Disk Controller (RDC) is capable of operating up to four Shugart SA4000 disks. 
The RDC controls disk formatting, data buffering, error checking and ECC syndrome 
generation, data transfers to and from the DO, and generation of wakeup requests for the 
disk microcode. The RDC also contains self-test logic with which a program can simulate 
the disk drive and exercise the controller on a clock-by-clock basis. 

8.2 Disk Characteristics 

The principal characteristics of the SA400Q disk are shown in Table 8.1. The unformatted 
capacity of the disk is 29.1 Mbytes. The useful data capacity after formatting is 45248 
sectors * 512 bytes/sector = 23.1 Mbytes. Each sector is formatted into three records, a 
header, a label, and a data record. Details of sector formatting are shown in Table 8.2. 
Each record in a sector may be independently read, written, verified, or not accessed, 
subject to limitations imposed by a command decoding PROM in the controller and to the 
restriction (imposed by read-amplifier recovery time) that a record cannot be read following a 
write to the preceding record. 





Table 8.1 


Number of tracks 


202 


Number of surfaces 


4 


Heads/surface 


2 


Bytes/track 


18000 


Sectors/track 


28 


Total sectors 


45248 


Transfer rate (peak) 


7.1 Mb/sec (2.2 us/word) 


Rotation time 


20ms 



Seek time (min/avg/max) 20/65/140 ms 
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Figure 8.3 RDC Output and Incut Registers 
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Table 8.2 -Sector Format (as written) 



Use: 



Bytes: 



Preamble 


13 


O'S 


Sync 


1 


00001010 


Header 


4 




Header CRC 


2 




Postamble 


5 


The write 


Preamble 


10 


0*s 


Sync 


1 


00001010 


Label 


16 




Label CRC 


2 




Postamble 


5 


The write 


Preamble 


10 


O's 


Sync 


1 


00001010 


Data 


512 




Data ECC 


4 




Postamble 


3 


The write 


Recovery gap 


53 




Total Sector 


642 





The write gate is on only during the first byte 



The write gate is on only during the first byte 



The write gate is on only during the first byte 



8.3 DO - Controller Interface 

The DO and the RDC communicate using seven of the sixteen output registers and four of 
the sixteen input registers available to a controller. Figure 8.3 shows these registers. In the 
descriptions that follow, page references refer to the RDC logic diagrams. 

8.3.1 Output Registers 

The registers used to transmit information from the DO to the RDC are: 

0: GeneralReset (see "ErrReset" beiow). 

1: Drive/Head: This register is buffered and sent directly to the drive<s). Values of the head field >7 
select up to 8 optional fixed heads. After a drive change (or a Write Fault). -2 sectors must pass 
before the signal DevSelOK becomes true (pl3). DevSelOK inhibits writing. 



2: ErrReset: The RDC may be reset in several ways. RUN' OR GeneralReset = Reset, which sets 
the lOStrobe f-f (p2), clears the Wakeup Counter (p3), the Allow Wake f-f and the Seek Counter (the 
counter is loaded with 17b) (p4), portions of the Format Sequencer (p5) and the Buffer Control 
Sequencer (p6) the DevSelOK counter (pl3), and the Read Gate (pi4). Reset OR ErrReset also ciears 
the WriteFault f-f in the drive, the RateError f-f (pl3), the IntOp register (p4), the ReadError f-f (pH), 
and the Sxror Register and OFauit f-f (pl2). 
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3: DevOpRegLd: The DevOp register holds disk commands and the AilowWake bit (which must be 
set at each OUTPUT if wakeups are to be enabled). The command bits in the DevOp register are 
discussed below. 

4: BufOataLd: Data directed to this register is written into Buffer[MemBufAdr]. 

5: TestRegLd: This register allows a program to simulate all signals generated by the disk. For normal 
operation, bit 7 of this register should be cleared. 

6: MemBufAdrLd: This register holds the current pointer into the RDC's data buffer. 

7: PrimelData: This "register" must be accessed with an OUTPUT by the microcode before reading 
the first word of each sector from the data buffer. It loads the Idata register (p8) from the data buffer 
and increments MemBufAdr (p7). The data transmitted by the OUTPUT is ignored. 

8.3.2 Input Registers 

The four RDC input registers are: 

0: Controller ID: This register returns the controller ID (1407b). It is valid only immediately after a 
reset, since it contains the ServiceLate and WakeRequest bits. The WakeReq f-f will be set by the 
SectorWake sgnal at the next sector pulse, making ID = 1417b (although since AilowWake = 0, no request 
will be made to the DO). 

1: Status: This register contains the controller and drive status. The significance of the bits is as 
follows: 

bits 0-4: 

bit 5 s : ServiceLate: This bit is set if DevOp is loaded during the header or label field, or if 
<16 words have been delivered to the buffer when the header sync byte is found [Precisely, if 
MemBufAdr[2:3] = when sync is found} 

bit 6*: ServiceLate': This bit is here to ease the problem of Idata Parity generation. 

bit 7*: RateError: This bit is set if the Buffer Control Sequencer bit "RateErrorPossible" is 
set and the '2' bit of the Wakeup counter = 1. RateErrorPossible is only asserted during the 
data transfer phase of a WriteData or VerifyData operation; during these operations, if the 
processor falls more than one wakeup behind the disk's need for data, a rate error will be 
indicated. 

bit 8: SectorO: This bit is true for the duration of physical sector 0, i.e., from index to the 
next sector pulse. 

bit 9: TrackO: This is a signal from the drive, asserted when the heads are at TrackO. 

bit 10: Seek Complete: This is a signal from the drive, indicating that a previous seek has 
completed. After this signal becomes true, tne microcode must wait an additional 28 sector 
times (20ms) for the head arm to settle before doing a data transfer. 

bit 11: DevSelOK: This signal indicates that a drive is seiected, is ready, does not have a 
WriteFault, and has delivered at least two sector pulses since selection. 
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bit 12*: BufErn This bit is set during a write if data taken from the RDCs buffer has bad 
parity. 

bit 13*: RdEm This bit is set if the CRC fails during a header read (unless InhHdrAbrt a 1), 
or during a label read or verify, or if the ECC indicates an error during a data read or verify. 

bit 14": WriteFault This is a signal from the drive, indicating that a problem that would 
cause errors during a write exists. 

bit 15*: OFault: This line is a latched version of the OFault line from the DO, which indicates 
that a double-bit error was detected during a memory reference. 

Bits marked with • set Abort and remain set until explicitly cleared by En-Reset or GeneralReset.. 

12b: This register provides loopback for ail signals transmitted to the drive. The sampling point for 
these signals is the disk cable, so ail the controller logic may be tested (even without a disk). 

17b: This register presents Buffer(MemBufAdrj. When accessed, MemBuf Adr is incremented and the 
Idata register is loaded from the buffer. 



8.3.3 Seek Control 

The head positioning in the SA4000 is done by a stepping motor driven by pulses from the 
controller. The direction of head motion is controlled by a single bit. The drive contains a 
"buffered step'* option which absorbs these step pulses more rapidly than the motor can 
move, and drives the motor at the correct rate; the RDC requires this option. Stepping is 
performed by two bits of the DevOp register. When an OUTPUT is done to the DevOp 
register with the seek bit (bit 5) equal to one, a single step pulse is issued to the drive. The 
value of DevOp.06 determines the direction; a one implies an inward step, i.e. toward higher 
track numbers. The RDC contains logic to generate step pulses of the proper width. The 
disk microcode must not issue OUTPUTS with seek ■ 1 more frequently that every 16 
microinstructions, or this logic will be defeated. During a seek sequence, when the 
microcode has delivered the last seek pulse, it must clear the seek bit in the DevOp register, 
since this bit inhibits sector wakeups, and also forces the Format and Buffer Control 
sequencers to be idle independent of the command fields of DevOp. The Direction bit 
should not be changed for ~2us after the last seek pulse is sent, or the disk will be 
confused. 



8.3.4 Disk Commands 

The RDC is capable of executing four basic commands during each record of a sector. 
Read, in which data is transferred from the disk to memory. Write, which Is the inverse, 
Verify, in which data from memory is compared with the data on the disk, and NoOp, which 
does nothing. If an operation in a record fails due to an error or to a non-compare on a 
Verify operation, the Abort flip-flop is set, and commands for subsequent records will be 
converted to Nops. During the header field, Verify is the only operation provided: the 
microprogram must supply data to be checked, and if if operations on subsequent records 
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are desired even if the check fails, the InhHdrAbrt bit in DevOp must be set. The label 
record is handled similarly. The microprogram must always supply data to be verified, but if 
the command is Read, the setting of Abort is inhibited. (Note that the operations on the header and 
label records are logically identical, but different mechanisms are provided to obtain the desired effect). 

The basic commands are implemented by two automata, the Format Sequencer (section 
8.4.3) and the Buffer Control Sequencer (section 8.4.4). The combination of legal commands 
for all records is determined by a PROM that examines the IntOp register and maps the 
commands into starting addresses for the sequencers if the combination is legal, or into 
Nops if the combination of commands is not legal. [Note: there is no way for the microcode to 
determine that an illegal command has been supplied to the controller]. The Command sequences that 
are currently implemented in the RDC are: 



Header 


Label 


Data 


Nop 


Nop 


Nop 


Verify 


Nop 


Nop 


Verify 


Write 


Nop 


Verify 


Write 


Write 


Verify 


Read 


Nop 


Verify 


Read 


Read 


Verify 


Read 


Verify 


Verify 


Read 


Write 


Verify 


Verify 


Nop 


Verify 


Verify 


Read 


Verify 


Verify 


Verify 


Verify 


Verify 


Write 


Write 


Nop 


Nop 



8.3.5 Wakeups and 10 Attention 

Wakeups are initiated by the RDC under two circumstances: A sector wake is generated at 
the end of the data record (-58 us before the physical sector pulse) if the basic sequencer 
operation (section 8.5) is Nop, Read, or Write [Note that Verify Data does not generate a sector 
wakeup. Instead, it generates an extra data wakeup, which is logically the same]. When the seek bit in the 
DevOp register is set, sector wakeups are inhibited. Sector wakeups originate in the Format 
Sequencer. 



Data wakeups are generated by the Buffer Control Sequencer. The exact timing for data 
wakeups depends on the record and the operation, and is described in section 8.4.7. Data 
wakeup requests are accumulated in a four-bit up-down counter that is constrained to count 
between and 17b. When the Buffer Control Sequencer issues a wakeup request, the 
counter is incremented; when the DO issues an 10 Strobe, the counter is decremented. The 
actual wakeup request is transmitted to the DO if the disk task is not running and if the 
wakeup counter is nonzero. 

When the disk task is running, 10 Attention is transmitted to the DO if the RateError or Abort 
bits are true [Note that Abort does not appear in the status register. The only way that a verification error 
can be inferred is to see lOAttn true, then read the status register and check that the other reasons for setting 
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Abort are not true]. 
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8.4 Hardware Organization 

The overall organization of the RDC is shown in figure 8.4. The page numbers in the figure 
refer to pages in the logic diagrams. The RDC contains a single data buffer of 256 16-bit 
words plus a parity bit. The buffer is addressed by two pointer registers, one used by the DO 
(MemBufAdr), and one used by the controller (DevBufAdr). During a disk write, data flows 
from the DO via the Odata bus into the Odata register, then into the buffer. As the disk 
requires data, it is transferred from the buffer to the output holding register, then into the 
shift register, where it is serialized and sent to the disk. During a read, data is deserialized 
in the shift register, placed in the input holding register, and sent to the buffer as new data 
arrives. From the buffer it is sent to the Idata register, then to the DO via the Idata bus. 

The DO has highest priority for buffer access. When it needs to read or write the buffer, the 
Buffer Control Sequencer Clock is witheid for a Cycle [note that this implies that if 16 word transfers 
are done by the disk microcode, the DO's efective clock rate (including cycles lost for BranchBurp) cannot be 
slower than -125 ns, since the disk transfers a word every 2.2 us, and the Buffer Control Sequencer must be 
able to access the buffer once per word]. 

During a write or verify operation, data from the DO is parity-checked by serial logic 
associated with the shift register. During a read, this logic generates the parity bit that will 
be sent to the DO. 

The RDC writes and checks a 16-bit CRC on the header and label records, and a 32-bit ECC 
on the data record. The CRC and the ECC are generated and checked by logic in the 
controller. If the ECC fails, the final syndrome can be recovered by the disk microcode so 
that a program can correct the data record. 



8.4.1 Timing 

The derivation of the timing signals in the RDC is shown in figure 8.4.1. The basic clock is 
the disk PLOCIock, which is read from a timing track unless the disk is reading, when it is 
derived from the recorded data. After level conversion, the clock is gated with the output of 
a counter which ensures that when ReadGate ♦■ 0, the clock is disabled for four cycles to 
avoid any discontinuities. 

DevClk occurs once per bit (1.1 us); the disk ByteCJk (which occurs every 8 bits) is 
generated by a PROM/register automaton. This logic also creates the XferData and 

LoadRec signals which occur once per wori [these signals h?ve ^r.ticai timing]; and the 
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8.4.2 Sequence Address Generation 

The operations that will be performed during each of the three records of a sector are 
controlled by a two-bit and two three-bit fields of the DevOp register. The disk microcode 
must load this register with a command before the physical sector pulse occurs (-58 usee 
after the sector wakeup). When SectorMarkSP occurs, the eight bits of the DevOp register 
are mapped into six bits, and loaded into the IntOp register. The mapping is performed so 
that the commands for each record will be encoded into a single bit. The encoding is: 

IntOp bit DevOp bit 

HdrWrt <- WriteHeader (DevOp.08) 

HdrRd «- ReadHeader (DevOp.09) 

LblWrt '«- WriteLabe! (DevOp. 10) 

LbJRd «• ReadLabei (DevOp.11) OR VerifyLabei (DevOp.12) 

DataWrt «• WriteOata (DevOp.13) OR Verify Data (DevOp.15) 

DataRd «• ReadData (DevOp.U) OR VerifyData (DevOp.15) 

The six bits of the IntOp register and two bits of a counter that indicate the record about to 
be processed (SeqCnt.0,1) are mapped by a 256 x 4 PROM (gll) into a four-bit Sequence 
Starting Address, SeqAdr.0-3. This address is used to determine the starting address of the 
code for the record in the Buffer Control and Format Sequencers. 

8.4.3 Format Sequencer 

The Format Sequencer is shown in figure 8.4.3. This logic controls the formatting of 
data on the disk, and is synchronous with the disk ByteClk. The sequencer is 
implemented as a finite state machine controlled by a 256x28 PROM. The PROM 
produces the most significant seven bits of the next sequencer address to be 
accessed, five bits of data used to load a counter described below, a test bit, and 
fifteen control bits. 

The flow of control in the format sequencer is determined by the BrOnSync bit The 
least significant PROM address bit, ForSeqAdr.7 = [(ForCntCry and BrOnSync') or 
(SyncFound and BrOnSync) or (FirstSequenceLocation)]. 

The format sequencer counter is loaded whenever ForSeqAdr.7 « 1. This counter 
contains five bits, and is loaded from five bits of the sequencer PROM (dForCnt[0:4]). 
The counter is incremented by ByteCLK, which also clocks the sequencer output 
register. 

The starting address of the sequence associated with a particular physical record is 
loaded into the address register at the start of the record. This address is 
SeqAdr[0:3]„Q000, but the PROM location accessed is odd because of the inversion in 
the least significant bit of the address. 
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The sequencer will access the location corresponding to the first location of the 
sequence, and (because this address is odd) the counter will be loaded from the count 
field of the PROM. 

When the sequencer is executing an instruction from an odd location of the PROM, the 
counter will have just been loaded. If the count value # 37b, the next instruction will 
be taken from an even location. If the counter was loaded with 37b, the next location 
will be taken from an odd location (since the counter will be producing a carry, forcing 
ForSeqAdr.7 to one). 

When the sequencer is used to time events during a record, the normal situation is that 
an odd location (e.g. X) will point to an even/odd instruction pair (Y and Y + 1) and the 
count field of X will contain 37b minus the number of ByteClk times that the sequencer 
is to execute instruction Y. The Next Address field of instruction Y will point to itself, 
so it will be executed repeatedly until the counter = 37b, at which time location Y+1 
will be accessed. Location Y + 1 will contain a new address and count, and the 
sequence will continue. 

As mentioned earlier, if the odd location of a pair contains 37b in its count field, it will 
go directly to the odd location of the new pair, since the counter will produce a carry 
as soon as it is loaded. 

When reading from the disk, the start of the sector is not precisely positioned, since 
the read clock (ByteClk) must be acquired by a phase-locked loop. The start of each 
record is indicated by a unique 'sync pattern' written before the data, and there is logic 
to detect this pattern. When the sequencer is generating SyncTime, this logic is 
enabled, and the BrOnSync bit is provided to test the SyncFound signal that it 
generates. Once the sync pattern has been acquired, the sequencer is precisely 
aligned with the disk data, and can therefore determine when to generate the control 
signals associated with the transfer. 

8.4.4 Buffer Control Sequencer 

The buffer control sequencer is shown in figure 8.4.4. This logic controls the transfer 
of information between the data buffer and the two device holding registers. This 
sequencer is synchronous with the processor. It is implemented as a finite state 
machine controlled by a 256x16 PROM The cutout bits cf the sequencer are divided 
into three fields as follows: 

1) BufSeqAdr[0:7j: This field selects the next address from the 256 word 
PROM. The three most significant bits of this register are loaded from 
SeqAdr[1:3] at the start of every disk record (Header, Label, Data, and 
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Recovery Gap), providing that SeqAdr.O = 0. If SeqAdr.O * 1, indicating that 
no data transfer will be done during the record, these bits are cleared. 
BufSeqAdr[0:3] are not changed during a record. BufSeqAdr[3:6] are loaded 
with zero at the start of every record. The least significant address bit, 
BufSeqAdr.7, is normally true, but may be made false by [(XferDataS and 
BrXfer) or (Counter =s15d and BrCry)]. BrXfer and BrCry are two control bits 
that provide a conditional branch capability. XferDataS is a processor- 
synchronous version of the XferData signal from the Format Sequencer. It is 
set when XferData is asserted (indicating that a transfer between the buffer and 
one of the device data registers is required), and cleared when the Buffer 
Control Sequencer asserts IncDevBufAdr. XferDataS is also cleared by 
Sequence End. 

2) Counter Control and Branch Bits. The Buffer Control Sequencer contains a 
four-bit counter that may be loaded, incremented, cleared, and tested for carry 
under control of five sequencer output bits. The counter and its control bits 
are local to the sequencer, and are not used anywhere else in the RDC. 

3) Buffer and Wakeup Control bits. These six bits are the outputs of the 
sequencer used to control the data buffer and the wakeup logic. The bits are: 

Data Wake: Increments the wakeup request counter. 

ClrMemBufAdr: Gears the buffer address register used for DO-buffer transfers. 

IncDevBufAdr Increments the buffer address register used for device-buffer transfers. 
This register is also cleared by the CIrOevOpS bit from the Format Sequencer. 

Dev^Buf: During disk writes, loads the buffer holding register. When the seriaiizer 
needs a word, it will be loaded from this holding register under control of the Format 
Sequencer/Timing Generator. 

WriteBuf: During disk reads, this bit causes the data in the serialized s output holding 
register to be written Into the buffer. 

Rate Error Possible: See section 8.3.2 

8.5 Basic Sequencer Operations 

The Format and Buffer Control sequencers in the RDC are capable of eleven basic 
operations. The Sequence Starting Address PROM (gii) determines which operations will 
be executed based on the current record number and on the command in the IntOp register. 
Each operation transfers data between the disk and particular buffer locations, causes 
wakeups at defined times, and leaves the device buffer pointer at a fixed location when the 
operation is completed. In what follows, the number of an operation is the value of 



Section 8: Rigid Disk Controller 103 

SeqAdr[0:3]; recall that if SeqAdr.O = 1, the Buffer Control Sequencer does not participate 
in the operation, but instead executes routine (seek). The descriptions assume that the 
DevBufAdr register (the buffer pointer) is cleared before a sector starts. The eleven routines 
are summarized here. The contents of the buffer control and format sequencer proms are 
shown in Appendix D: 

0: Seek: This operation transfers no data and requests no wakeups (sector wakeups will be disabled 
as long as this operation is in the DevOp register). 

1: Write Header: This operation writes two words from buffer locations and 1 onto the disk. It 
then increments the buffer pointer by 2, leaving it at location 4. No wakeups are generated by this 
operation. 

2: Read/Verify Header: This operation first transfers two words from buffer locations and 1 to the 
output holding register (this is the data to be compared with disk data). The microcode is assumed to 
have loaded the buffer before the operation started. It then takes two words from the input holding 
register (the data read from the disk), and places them into buffer locations 2 and 3. The operation 
leaves the buffer pointer at location 4. When the operation is complete, a wakeup is requested. 

3: Write Label: This operation transfers data from buffer locations 4 through Hd to the disk. It then 
increments the buffer pointer four more times, leaving it at location 16d. No wakeups are requested by 
this operation. 

4: Read/Verify Label: This operation first transfers two words from buffer locations 4 and 5 to the 
output holding register. At the end of this section, the device shift register will contain the first word to 
be verified, and the output holding register will contain the second word. At the next six XferDataS 
times, a word will be transferred from the buffer to the output holding register, a word will be 
transferred from the input holding register to the same location in the buffer, and the buffer pointer will 
be incremented. At the end of this section, the first six label words will be in locations 6 through 11 d, 
and a wakeup will be requested. At the next two XferDataS times, a word will be transferred into the 
buffer, getting the last two label words. Finally, the pointer will be incremented by two, and a wakeup 
will be requested. The label read from the disk will be in buffer locations 6-1 3d, and the buffer pointer 
will be at I6d. 

5: Write Data: This operation transfers the first data word to the disk from buffer location I6d, then 
requests a wakeup. It then transfers sixteen words to the disk with RateErrorPossible = 0. Then,, it 
repeats a loop in which it requests a wakeup, then transfers 16 words. During this loop, 
RateErrorPossible = 1. All transfers from the buffer to the disk are done in response to the XferDataS 
bit from the Format Sequencer/Timing Generator. 

6: Read Data: First, this operation increments the buffer pointer (to 17d). It then transfers 17d words 
from the disk to the buffer, and requests a wakeup. From this point until the end of the record, it 
loops transferring I6d words into the buffer and requesting a wakeup. 

7: Verify Data: The sequence of events during this operation is identical to that for Write Data. 

10b: Nop Header: This operation does no data transfers and requests no wakeups. Only the Format 
Sequencer participates - it is used only to time the duration of the record. 

Mfc:Nop Label: Same as Nop Header (except longer record). 

12b. Nop Data: This operation times the iength of the Data Record and generates a sector wakeup at 
the end of the field. It has no other function. 

17b: Recovery Gap: This is a Format Sequencer operation used to wait for the next physical sector 
pulse. 
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8.6 Error Correction 

The header and label fields of a sector are error-checked using a F9401 CRC generator that 
writes a 16-bit CRC following the record. The CRC is not available to the disk 
microprogram - the only indication of an error is the RdErr bit of the status register. 

Error correction of the data on the SA4000 is done by appending a number of check bits to 
the data record. The correction must be done by a program, given a syndrome generated 
by logic in the controller. The code used is a binary cyclic code known as a Fire code. A 
cyclic code is characterized by its generator polynomial g(x); for the Fire codes, g(x) has the 
form: 

g(x) = P(x) (x c -1), 

where P(x) is an irreducible polynomial of degree m and order e, and c is not divisible by e. 
(x c -1) is referred to as the pattern polynomial, and P(x) is the displacement polynomial. The 
length n of the code is LCM(e,c), the number of check bits is (m + c), and the number of 
information bits is k= n-m-c. Such a code can correct a burst error of up to m bits. 

The particular code used in the RDC has: 

g(x) = (x 11 + x 2 + 1) (x 21 + 1). 

The order of P(x) is 2047, m = 1 1 , and c = 21 . The number of check bits is therefore 32, and 
the length of the code is n = 42987 bits. The maximum number of information bits is 42955, 
or 2684 words. 

The choice of generator polynomial and the associated hardware design are originally due to 
R. Bates, and are employed in the Alto Trident disk controller [see Bates, R. "trident disk for the 
alto" ,parc csl memo, 11 August 1976]. The theoretical background for Fire (and other) codes 
is developed in Peterson, W., "Error Correcting Codes", MIT Press, 1961. The correction 
procedure suggested here is a variation of that suggested by Peterson in section 10.6. 

The hardware used to mechanize the code is shown in Figure 8.6a. Figure 8.6b shows the 
configuration provided when data is being written on the disk, and Figure 8.6c shows the 
configuration during reading. During writing, the data is premultiplied by x 32 (to make room 
for the 32 check bits at the end of the record), and divided by g(x). After the data portion of 
the record has been written, the shift register holds the remainder from the division of M(x) 
by g(x). where M(x) is the polynomial representation of the data record. At this time, the 
•eecoacK patns are disabled and the remainder (the check bits) Is written on the disk. 

During reading, the shift register is reconfigured as shown in Figure 8.6c, and two 
independent divisions by P(x) and (x c -1) are performed. When the data record has been 
processed, the shift registers are reconfigured with the feedback paths disabled, and the 
resulting syndrome is shifted into the data shift register, then sent to the RDC's data buffer. 
The syndrome is placed in words 23b (syndrome bits 0-15), and 24b (bits 16-31), where they 
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can be accessed by the microdcode if an error occurs. 

If no error occurs during reading, both the pattern register and the displacement register will 
contain zero. If a correctable error occurs, both these registers will be nonzero. The 
correction procedure must be done by a program using the syndrome recovered from the 
hardware. For clarity in what follows, it will be described as if it were done in the 
displacement and pattern registers. 

The first part of the correction procedure isolates the burst pattern. The contents of the 
pattern register aire cycled until the least significant ten bits are zero. If this does not occur 
within one complete cycle (21 shifts), an uncorrectable error has occured. Let the number 
of shifts required to isolate the error pattern be S Q . The error pattern (which will eventually 
be xoRed with the data record is now in the most significant eleven bits of the pattern 
register. 

To find the position of the error burst, the displacement register is clocked with the input 
equal to zero until its contents are equal to the most significant eleven bits of the pattern 
register. This will occur within 2047 shifts; let the number of shifts required to satisfy the 
condition be S-. [Note: The implementation chosen premuitipiies the displacement polynomial by x , which 
is equivalent to providing eleven shifts of the pattern register in advance. When S^ is determined, it must be 
corrected by doing S 1 «• (S 1 + 11) mod 2047.] 

The location d of the error burst relative to the beginning of the record is now determined 
[note that the M beginning H of the record is the beginning of the longest message the code is capable of 
correcting, 42987 bits. We are using a shortened form of the code, with zeros at the beginning of the 
messages. This does not change anything]. We know that: 

5 a d mod c (c » 21), and 

5 1 * d mod e (e » 2047). 

Since c and e are relatively prime, they can be used as the moduli m. of a modular number 
system, and the Chinese Remainder Theorem [see Knuth, 0., "The Art of Computer Programming" , vol. 
2, p249] guarantees that d is unique. To calculate d, we use: 

d » [ S (A *M/m ) + St (A/M/nr^) ] mod M, 

A Q and A^ are constants such that A. m M/m ] a 1 mod m., and M is m *m r R. Bates has 
supplied these constants; they are A = 19, A.,' » 195, so: 

d = [ S (19*2047) + S 1 (195*21) ] mod 42987 

d is the displacement from the beginning of the record. To determine the location relative to 
the end of the record, use 42987 - d. Once the displacement is determined in this way, the 
burst pattern determined earlier is xoRed with the appropriate bits of the record. 
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APPENDIX A 



Time of Day Clock 



;This is the program for the Time Of Day Clock in the MSI - DO. 
;It Runs on a TI TMS1000C microprocessor. 

The programs outer loop runs once per second. 

Each time through the loop, it generates a one instruction time 

long pulse on OneSecondPulseR (for testing). 

It increments a 32 bit counter TimeOfDay once per outer loop time. 

The microprocessor has one of its K inputs tied to the 5 volt supply of the 
DO. If the power to the DO is on (PowerOnK), the program increments 
PowerOnTime in the same manner as Time Of Day (32 bit count of the 
number of seconds) . 

The program compares the TimeOfDay to another variable, AlarmClockTime 

If TimeOfDay » AlarmClockTime, the program will 

set the TurnProcessorOn R output (which will generate a 1 second pulse). 
It will also set the AlarmClockLatch R output, which will stay on until 

explicitly cleared. 

The current TimeOfDay is broadcast bit serially on the OutputData R output of 
the TMS1000. The data is broadcast once a second and consists of one start 
bit (a 1), 56 data bits (of which only the last 32 are significant), and 
943 stop bits (Os). 

A bit time is one millisecond. Since the message is 1000 bits long, 
at one ms per bit, this is one second per transmission. 
The time is broadcast msb first. 

During the time the program is broadcasting Time of Day, it also 
accumulates a message, bit serially, on the Input Data K input. 
The input data is sampled at the end of a bit time (ie the program sets 
the R output, waits 1 millisecond, then samples the input data). 
The input message is 56 bits and consists of a 16 bit password, 
an 8 bit command field and a 32 bit Data field. After all 56 bits are 
accumulated, the program checks the password field. 
If it contains A1F5 (hex) [Sesame], the message is considered valid 
and the command field is acted upon. 

An invalid message is ignored, and the program reverts to sending Time of Day, 
no matter what it had previously been directed to transmit. 
No messsages are gathered or sent unless the DO has power. 

The command field of a message is interpreted as follows 

Bit TimeOfDay «■ Data 

Bit 1 PowerOnHours «• Data 

Bit 2 AlarmClockTime «• Data 

Bit 3 Fudge «• Data (low 16 bits) See below for explanation of Fudge 

Bit 4 Clear AlarmClockLatch 

Bit 5 Transmit PowerOnTime instead of TimeOfDay 

Bit 6 Transmit AlarmClockTime instead of TimeOfDay 

Bit 7 Clear PowerOnLatch (obsolete function) 

Bit 5 and 6 of the command field alter the data that is broadcast. They are 
used to read out PowerOnTime and AlarmClockTime. Note that bits 0:15 
of the 56 bit output message are the value of Fudge when bit 5 of 
the command field is set (ie you get both fudge in 8:23 and PowerOnTime 
in 24:56). 
The effect of bits 5 and 6 is continued until reset by another command 

• (with 0s in 5 and 6) 

The program is written so that all branches result in exactly equal number 
of instruction executed. The time base is thus the TMSlOOO's clock, 
which is crystal controlled at 1 MHz. Because the crystal may not have 
enough calibration accuracy, the program maintains a variable (Fudge) 
which is used to adjust the time base. Fudge is counted down to 
at the end of the main loop. The nominal value of Fuoge (a 16 bit numoer) 
is 3000 (hex). By changing the value of Fudge, the DO can adjust the 
time base of the microprocessor. Fudge's accuracy is 2 instructions 
(ie setting Fudge to 13 will cause 26 more instructions to execute). 
The TMS1000C takes 5 cycles per instruction, so each Fudge count 
at 1 Mhz is 12 usee. 

To safeguard against invalid data due to loss of power or other causes, 
the program checks a 16 bit variable Masterlock against a constant 



(A1F5, the same Sesame as the input password). If MasterLock is not Sesame, 
The program will zero out TimeOfDay. MasterLock is set to Sesame upon 
receipt of a valid command. The intention is that when the microprocessor 
has a hiccup or power failure, the registers will be scrambled. The program 
detects this and causes time to be frozen at 00001 until a valid 
command is received 

The algorithm, in pseudo code is: 
forever do 
begin 

TimeOfDay <- TimeOfDay + 1 

R.TurnProcessorOn <- if AlarmClockTime s TimeOfDay then 1 else 
if K.PowerOn then 
beg i n 

PowerOnTime «• PowerOnTime + 1 
R.OutputOutputData «- ! Start Bit 
BitDelay() 

for NibNum * 13 to by -1 do 
begin 

OutputNibble - case Readout of 
case 2: PowerOnTime[NibNum] 
case 4: AlarmClockTime[NibNum] 
default: TimeOfDay[NibNum] 
for BitNum - 3 to by -1 do 
begin 

R.OutputData «- OutputNibble AND 8 ! send msb 
OutputNibble <- OutputNibble Ishift 1 
BitDelay() 

InputNibble <- (InputNibble Ishift 1) + K.InputData 
end IBitLoop 
Input[NibNum] «- InputNibble 
end INibLoop 
R.OutputData «- 1 !Stop Bits 
if Input. Password = Sesame then 
begin 

if Input. Command AND 128 then TimeOfDay «• Input. Data 
if Input. Command AND 064 then PowerOnTime «- Input. Data 
if Input. Command AND 032 then Fudge <- Input. Data & 177777b 
ReadOut «- Input. Command & 17b 
MasterLock «• Sesame 
end !Val idMessage 
if MasterLock # Sesame then TimeOfDay ♦■ 
end ! Power On 
Delay(XXX) IRound out time to an even second 
Delay(Fudge) 
end 

last modified May 15, 1979 2:53 PM by CPT 

This program is assembled using a variant version of BCA (available from CT) 

The output file from BCA ("tod.mb") is then run through FIXTODMB .RUN, which produces 

"todprom.mb" and "todprom. 1 ist" . Todprom.mb is then put into a 2708 EPROM. 
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MC1 and MC2 Microcode 
(These are descriptions of MC1 revision E, MC2 revision D) 
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36 



10 



33 



MClClKOutPUt 34 



13 



15' 



16* 



17' 



25' 



26' 



35' 



27 



28 



32 



21 



22 



23 



24 



20 * 



37 



38 



39 



12 



18 



29 



_3£L 



31 



Prom Bit Number 
(* indicates low 
true in prom) 



MC2 R conflict 



— Used here to clock H4ParityError flip-flop 



L 



Goes to location 2 if 
H4 Parity Error (see IO Store 4) 
H4 loaded 

Note: Pipe gets Type/task only, other 
words are garbage 
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memop07.sil 



PS10 



Operation: pstore 1 ,2 

PS11 



PS13 



M C1 : current 




































abort 


fault 




A 






F 


























a 






f 




Next 


A 






F 






































F 


MCINext.0 














































MC1Next.1 1 














































MC1Next.2 2 














































MC"INext.3 3 














































MC1Next.4 4 


9 











1 


1 


1 


1 1 


1 


1 


1 


1 


1 


1 


1 





















MC1Next.5 5 














































DreMClNext.6 6 














































preMClNext.7 7 














































MC1TestH4Par 8 














































MdTestFauit 9 








■ 






































MClTestQWO 36 


■ 












































MClSetFault 10 










































■ 




PreioadMCl 11* 






























■ 


■ 




■ 


■ 








MClStartMC2 33 












■ 


































MdClkOutout 34 












■ 


































IMux«-Cdat 13 






















■ 


■ 


• 


■ 


















H4-iMux 14 






















■ 


■ 


■ 


a 


















MaoRAS 15* 




































■ 










MapCAS 16* 










































■ 


■ 


Mao Write 17* 














































MClRef 25" 










a 




































MCI Store 26 • 










a 




































PreRowAd 35* 






■ 








































StorRAS 27 










































■ 


■ 


StorCAS 28 














































MClWriteMem 32 
































■ 














MC1Ploe.1 21 








■ 


a 


■ 






























■ 


■ 


MC1 Ploe.2 22 




■ 






a 


■ 






























a 


■ 


MClPioe.3 23 






■ 






■ 
































a 


LoadPioe 24 










































a 


■ 


R«-P*oe 20 • 














































LoadH3l 37 














































MClNeedsR 38 














































MClWriteR 39 














































R*-H3I 19* 














































GenPhaseO 12 
























■ 






















IVaiid 18 














































MClSXoort 29 
























■ 


■ 


■ 


• 
















MClLoadD 30 




























■ 


■ 
















MdLoadW 31 


























■ 




■ 
















I 

Prom 8i 
C indlc. 

MC2: truainp 


ate 


lui 
m 


Tit 

101 

) 


tei 










P£ 
P 


L 
* 


H 
C 

Is 


4* 
I 


-R 
It 

P 


/ 

2$ 


L. 






Fe 


tc 


LI 
h error 







Cannot cause H4 ParityError, since 
EnlnputParChk is false during PSTORE 1,2 



Current 


















E 










e 




Next 
















e 








9 






F 


MC2Next.O 
































MC2NexM 1 
































MC2Next.2 2 
































MC2Next.3 3 
































MC2Next.4 4 
































MC2Next.5 5 




9 





1 


"J 






















MC2Next.6 6 







1 


fi 


1 






















oreMC2Next.7 ' 7 
































MC2TestSE 8 
































MC2TestOE 9 
















■ 
















MC2HcidlfSNE0 10 i 






























MC2SetFauit 11 




























■ 




VC2Stjr:Xaert *5 
































MC2Hoid 16* 




























■ 


a 


ChkPhaseO 12" 






a 


























LoadSvndrome 13 












■ 




















MC2NeedsR 13" 












■ 


■ 


a 


a 










a 




MC2NeedsRlfSNE0 19 
































MC2WriteCdat 17 
































MC2oreLoadOdata 14' 

































— Single errors on the read are not checked or 

logged, since the data will be overwritten immediately. 



MC2 does R access. Write is inhibited on the ALU card 



first Cdat word ready 



9/24/78 
Memop08-09.sii 



PS411 



PS42 PS410 P§£3 I 

YUl^-l ■ . i j 


It 


VIUl. Current U 


F u 




f 




Next U 


F I 


1 






MCINext.0 










MC1Next.1 1 










MC1Next.2 2 










MC1Next.3 3 










MC1Next.4 4 OOOO 


110 C 


) 





n 


MC1Next.5 5 










DreMC1Next.6 6 










preMC1Next.7 7 










MC1TestH4Par 8 










MClTestFault 9 


■ 








MClTeejtQWO 36 










MClSetFautt 10 






■ 




PreioadWICl 1 1 • 


■ ■ 








MC1StartMC2 33 










MClQlkOutput 34 










lMux<-Cdat 13 










H4«HMux 14 










MaoRAS 15* ■ ■ ■ ■ 


■ ■ i 


i 






MapCAS 16* ■ ■ "I 


■ ■ ■ ■ 


i 


■ 




Map Write 17* 










MClRef 25* "" 


■ 








MCI Store 26* 


■ 








PreRowAd 35* ■ 










StorRAS 27 ■ 






■ 




StorCAS 28 


■ ■ ■ ■ 




■ 




MClWriteMem 32 


■ 








MC1Pipe.1 21 ■ 


■ ■ 




■ 




MClPipe.2 22 ■ 


■ ■ 




■ 




MC1Pipe.3 23 ■ 


■ 




■ 




Load Pipe 24 ■ ■ ■ ■ 






■ 




R*-Pipe 20* 










DadH3l 37 










MClNeedsR 38 ■ ■ ■ 


■ 


■ 






MClWriteR 39 










R*-H3I 19* 










GenPhaseO 12 ■ 










IVaiid 18 










MClSXpprt 29 ■ 


■ ■ ■ 








MClLoadO 30 


■ ■ 








MClLoadW 31 | 


l-l - 








Prom Bit Number Re; 


idR 









Operation: pstore 4 



FAULTWAIT 



true In prom) 
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memoplO.sil 



Operation: o^put 



MCI: 

MC1N#&2. 



Currant 

N«Xt 



MC 1N«xt.1 




MClTeftH4f> y r 3 

MciStp^ix: 

MClT-tQWQ 36 



MCl^Fault 



10 



UJ 



_JJF 2E 
PreloadMCl 
MClStartMC2 33 

MC l6k6utDUt 34 



IM ux*»Cdat 



H4 «»JMux 



J2. 



14 



Ma oftAS 
Ma oCAS 



15' 



Map Write 



js: 



17' 



MC 1Re< 



MdStore 
Pr % flow Ad 
StorRAr 
Storg 



js: 



I 



ft 



27 



n 



MC1Wrtt T M.m 2 



MC 1PtO».1 
MC 1 Pjoo.2 



41 



MClSSZ 



3L 



teadPj££_ 



J3_ 



R-«ai. 



MC 1N— <3« 



JSL 



R- H3I 19* 



Ga nPh»a«0 
IV»« 



12 



mcjUesh: 



Ji 



Mciiajaa. 



Jl 



MClLo.dW 



.aa. 



31 



Prom Bit Number 
(* indicate* low 
true in prom) 



MC2: 



MC2Next.O 



Current 
Next 





MC2Next.1 



1 



MC2Next.2 



MC 2Next.3 



MC2Next.4 



MC2Next.5 



MC 2Next.6 



pre MC2Next.7 



MC 2TestSE 



MC 2TestQg 



MC2HoldlfSNE0l0 



MC2SetFauJt 



1 1 



^C2StartXaort 15 



MC 2Hotd 



16' 



Ch kPhaseO 



12' 



Loa dS vndrome 13 



MC 2NeedsR 



18" 



MC2NeedsRlfSNE0 1S 



MC 2WhteCdat 17 



MC2preLoadOdata 14' 



OUTPU T 



oyjx 



Note: MC2Next.4 and MC2WriteC0at = > OVaiid in the Next cycle 



J 



OValids 1 
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Memopl 1 .s.i 



Operation: *o fetch 16 ^p 3 



IOF2 



)OF 3 



MC1 . Current 










r~ 


























fa 


Jit 










Q 






























q 




Next 








Q 





































MCINext.0 












































MC1Next.1 1 












































MC1Next.2 2 












































MC1Next.3 3 












































MC1Next.4 4 












































MC1Next.5 5 












































DreMClNext.6 6 












































DreMC1Next.7 7 












































MC1TestH4Par 8 












































MClTestFault 9 








■ 




































MCUestQWO 36 












































MClSetFault 10 








































■ 




PreloadMCl 11* 


































■ 


■ 








MC1StartMC2 33 












■ 
































MClClkOutout 34 












■ 








■ 








■ 








■ 








IMux«-Cdat 13 












































H4HMux 14 












































MaoRAS 15* 












































MaoCAS 16* 








































■ 


■ 


MaoWrite 17* 












































MC1Ret 25* 










■ 


































MC1 Store 26* 












































PreRowAd 35* 






■ 








■ 








■ 








■ 














StorRAS 27 








































■ 


■ 


StorCAS 28 












































MClWriteMem 32 












































MC1PiDe.1 21 








■ 


■ 


■ 




























■ 


■ 


MC1PiDe.2 22 




■ 






■ 


■ 




























■ 


■ 


MC1PiDe.3 23 






■ 






■ 






























■ 


LoadPiDe 24 








































■ 


■ 


R«-P$De 20* 












































LoadH3l 37 












































MClNeedsR 38 












































MClWhteR 39 












































R*-H3I 19* 












































GenPhaseO 12 












































IVaiid 18 












































MClSXDort 29 












































WICILoadD 30 












































MClLoadW 31 












































I 

Prom Bi 

(* indie 

KAno. true in F 


th 
ati 
>rc 


lu 
»s 

>m 


mt 
to 
) 




r 




























Double erro 


rs 





FAULTWAIT 



FA ULTWA IT 



Current 
Next 
MC2Next.O 



W 



W 



Vi 



Final Final 
Svnsp Svn#0 



no fault 



faul 



MC2Next.1 



1 



MC2Next.2 



MC2Next.3 



MC2Next.4 



MC2Next.5 



MC2Next.6 



preMC2Next.7 



MC2TestSE 



MC2TestDE 



MC2HoldlfSNE0 10 



•V!C25€tFault 



" oc :t^rt^ror + 



Ch kPhaseO 



12* 



LoadSvndrome 



13 



MC2NeedsR 



18* 



MC2NeedsRlfSNEO 1S 



MC2WriteCdat 



17 



MC2preLoadOdata 14' 



■ ■■■■■ 
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>nemop12.sil 



first Cdat word ready 




MCI: 



Current 

Next 



MC lNext.O 
MClNext. 



MCI Next. 2 



MC1Next.3 



MCI Next. 4> 



MC1Next.5 



oreMCiNext.6 



ore MCINext.7 



MC1TestH4Par 



MClTestFault 



MCTTestQWO 



MClSetFault 



PreloadMCi 



MC lStartMC2 
M OClkOutPut 



IMux^Cdat 



H4HMux 



MaoRAS 



MaoCAS 



Mao Write 



MCI Ret 



MC1 Store 



PreRowAd 



StorftAS 



StorCAS 



MClWnteMem 



MC1Pipe.1 



MC I Ptpe.2 



MClP*pe.3 



Lo ad Pioe 



R*-PiPe 



LoadH31 



MClNeedsR 



MC lWtlte R 

R«» H3I 



Ge nPhaseO 
iVaiid 



MClSXport 



MC I Load D 



MClLoadW 



36 



10 



11* 



33 



34 



13 



14 



15' 



16' 



25' 



26' 



35' 



27 



28 



JL 



21 



22 



23 



24 



20* 



37 



38 



39 



19" 



12 



18 



29 



30 



31 



Operation: 10 store 4 

IOS1 



FAULTWAIT 



— Load H3I to clock H3IParity flip-flop 



Prom Bit Number 
(* Indicates low 
true in prom) 



H4«-dev 
I data 



L 



On a parity error, an extra cycle is 
taken, and control goes to location 2 



5/4/78 
memop13.sil 



Operation: XMAP 



MC1: 



XMO XM1 



Current 
Next 



MCINext.0 



MCI Next. 1 



MC1Next.2 



MC1Next.3 



MC1Next.4 



MC1Next.5 



pre MC1Next.7 



MClTestFautt 



MClTestQWO 



MClSetFault 



P reload MC1 



MC 1 Start MC2 
MClClkOutput 



IMux«-Cdat 



H4HMux 



Ma pRAS 



Ma pCAS 



Ma p Write 



MClRef 



MCI Store 



PreRowAd 



Sto rRAS 



StorC AS 



MClWrtteMem 



MC 1Pipe.1 



MC lPipe.2 



MC1Pipe.3 



Lo ad Pipe 



R^ Ptpe 



-oadH3l 



MC1 Needs R 



MC lWriteR 
R«- H3i 



Ge nPhaseO 
IValid 



MC lSXport 



MCUoadD 



MCI Load W 



preMClNext.6 6 



MC1TestH4Par 8 



9 



36 



10 



11* 



33 



34 



13 



15' 



16' 



17" 



25* 



26* 



35* 



27 



28 



32 



21 



22 



23 



24 



20* 



37 



38 



39 



12 



18 



29 



30 



31 



I Phase 1 

Prom Bit Number 
(* indicates low 
true in prom) 



The operation proceeds in three phases: 

1) Load the pipe from the map entry for the selected VA. 

2) Read one word from R into H4, and write it into the map. 

3) Dump the pipe into the next 3 R registers. Only the entries 
which contain map data are dumped. 
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memop14.sil 



Operation: iostorei6 



MC1 . Current 










































fat 


Jit 










F 
































f 




Naxt 








F 






































MCINext.0 














































MClfiixt.1 1 














































MC1N«xt.2 2 














































MC1Next.3 3 














































MC1Next.4 4 














































MC1N*Xt.5 5 














































DreMC1N«xt.6 6 














































oreMCINext.7 7 














































MClTestH4Par 3 






































a 








MClTestFault 9 








a 






































MCUestQWO 36 














































MClSetFault 10 










































a 




PreloadMCl 11* 




































a 


a 








MClStartMC2 33 














































MClCJkOutout 34 














































IMux«-Cdat 13 














































H4HMUX 14 














































MaoRAS 15* 














































MapCAS 16* 










































a 


a 


Map Write 17* 














































MCJRef 25* 










a 




































MC1 Store 26* 










a 




































PreRowAd 35* 






■ 








a 








a 








a 
















StorRAS 27 










































a 


a 


StorCAS 28 














































MClWriteMem 32 














a 








a 








a 








a 








MC1Plpe.1 21 








■ 


a 


a 






























a 


a 


MC1 Ptoe.2 22 




■ 






a 


a 






























a 


a 


MC1P*oe.3 23 






■ 






a 
































a 


LoadPioe 24 










































a 


a 


R«-Pipe 20* 














































LoadH3l 37 














































MONeedsR 38 














































MClWrttefl 39 














































R*-H3I 19* 














































GenPhaseO 12 






■ 








a 








a 








a 
















tVaiid 18 














































MClSXoort 29 














































MClLoadO 30 














































MClLoadW 31 


„ 1 
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APPENDIX C 
Standard I/O Interface 



Shift 
Addrmss Register 



CH3-22lnL 



Caddr.O' 



Caddr.V 12 



Caddr.2' 13 



37j ?Rg*ock 



feel 



taddr.O 



laddr.1 



taddr.2 



167 1 )addr3 



S175 
DO 00 
Q0' 

01 Q1 

or 

02 Q2 
Q2 

03 Q3 
b!9Q3 

accy 



1 



Hf 



2 Caddr.O' 



3 Caddr.O 



7 Caddr.r 



6 Caddr.1 



10 Caddr.2' 



11 Caddr.2 
15 Caddr.3' 



1 * W4 




SROut 



4jH3 



S04 
(Mey use any inverting etement) 




g19 



18 taddr.O' 




g19 



16 laddr.r 




g19 



14 laddr.2' 




g1% 



12 laddr.3' 



S240 



Input 
Address Compere 



15 



13 



14 



12 



11 



10 



S85 
X>Y 



xo 

YO 

X1 

Y1 

X2 

Y2 

X3 g18 

Y3 

> a < 



X:V 



X<Y 



M 5 
6 IComoare 



Hi 



GNO 



IComoare 4 
IValid 5 



OCmof 



OValid 



d18b]o-S— 
y SOO 

~ J SOO 



!Me' 



OMe' 



in >a * dr * 



169 1 lad * r5 



czo 



laddr.6 



171 



laddr.7 



17 



J£ 



gj^O? Iaddr4 ' 
g ^s p ? laddr.5' 




13 




g19 



7 laddr.6' 



11 




g^fc o? Iad ^ 7 ' 



S240 



— 1 AdvancePioe* 2 




d1 



^P 18 AdvPipe 



S240 



p^ M<;2?tartXport 13 [^>I_ 
U^TS241 



65 



ivaiid' 




d19 



JS. 



S240 



QCompare 3 



1<;ompar» 4 



6 



11 



12 



13 



25S09 
00 



BO 
01 
B1 
02 
HB2 
03 
B3 



917 



QO 



Q1 



Q2 



Q3 



SB CK 



9 



EdqeClkV 



10 



15 



12 



IValid 



EdgeClk Feed 1 13 




11 



SOO 



2 OComoare 4 



12 



13 





S175 


00 QO 


QO' 


D1 Q1 


OV 


02 Q2 


Q2' 


03 Q3 


g16Q3* 


CKCL' 



2 OCmof 



HO Oaddr.6' 



H5 Oaddr.7' 



* 14 



1| Hi 



195 



OValid' 




S240 



OValid 



74 



OFault' 



L^n S241 



lOFault' 



S240 

dl9i 
EN' 



GNO 



1 ! 



S240 

d19j 

EN' 



S240 

g19i 

EN' 



S240 

9191 

6*' 



19 



S241 

c19i 

EN 1 



S241 

c19j 

EN 



GNO 




d19- 



12 



S240 



Hi 



iRevYoete I Pegs I 

C 1 r\& /-try /-to I « I 



XEROX Wc* 



in IMTCOCAPC AWHroee 






Designer 



Oda^-99 



Output 
Data Regist er 




OutD.OO 



OutD.01 



9"tp.o? 



OutP.03 



QutD.04 



OutD.05 



OutD.06 



OutD.07 



Odata.08 



ESQ 

rsD 0data - 09 




Out D. 08 



Out0.09 



OutD.10 



OutD.11 



OutD.12 



OutD.13 



OutD.14 



OutD.15 



[7T1 Odata.16 



,^TS241 



OutD.16 



RUN 



g X x iS241 



IRun 



EdgeClockFaed' 



RamClockFeed' 10 




3 EdgeClkFeedl 1 



Hi 2 



lOb P 6 £d 5 e ClkFeed2 



8 RamCIkFeedl 




SOO 



EdgeClkV 



XEROX 

EOD 



Project 

DO 



10 INTERFACE OData/Clocks 



File 

D0IO02.sil 



I Designer 

DPPStaff 



Rev I Date I Page 

B 05/10/781 2 



JEU. 



ja. 



-£2_ 



Transmit 



1^¥ 
10k 



WakePI ' 



■CD 



G123 2 



WakeP2 



'-en 




S32 



10 



WakeP3' py^ 



Transmit* 12 
Phaser 13 



38 
^/S32 1^x^3240 




a17b 



S32 



10 




a17c 



S32 



PToB 



Phase 1 Next' 



15 




i|3 



d19' 



soo 



PhaselNext 



S240 



Wake&eauest 



Wake enable 













PhaselNext! 1 3 


25S09 
DO 




? 


PhaseV 




10 


HM7603 

QO 

*n Q1 

A1 Q3 
^3 ° 4 


1 


1 4 
G1P2 6 


b6 Qo 

:; o, 

B2 Q2 
83 Q3 

83 b17 
SB CK 


7 


G1 




2 


G1P1 5 


GNO 


10 




3 


G2P2 11 




Caddr.O' 


11 


4 


G2P1 12 


G2 


Caddr.r 


12 


5 


G3P2 14 


15 




Caddr.2* 


13 


G3 


ft 


G3P1 13 


Caddr.3' 


14 


A4 


Qb 


7 


G123 










U6 


9 


G23 






Dlo w 

cs» 




1 
PhaselNext 


9 










GN 


15 
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APPENDIX D 
RDC Buffer Control and Format Sequencers 



The following code is for the Buffer Control Sequencer. The l's and 
O's are the address and data bits (x - don't care). The sequences 
have been given as programs to the right of the bits. 

Oata 8its Are: 

0-3: BufNxtAdr[3:6] 

4-7: dBrC.2, dlnC, dCIC , dLdC* 

8-11: dBrC, dBrX, dDtW, dClrMem8uf Adr' 

12-15: dlncOevflufAdr, dDev«-Buf, dWrtBuf, dREP 



Address: Oata: 

000 0000 x * 0000 0011 0001 0000 MoOataTransfer: goto[.]; 



001 0000 x * 0001 0011 0001 0000 WriteHeader: goto[.+l]; 

001 0001 1 * 0010 1010 0001 0000 Cnt «- 1110, goto[.+l]; 

001 0010 1 * 0010 0011 0101 0000 Waitloop: goto[.+l,., XferOataS]; 
001 0010 « 0011 0111 1001 1100 Dev «- Buf , IncBufAdr, IncCtr, 
goto[CntDone,CntWait,CntCry]; 

001 0011 1 * 0010 0011 0001 0000 CntWait: goto[WaitLoop] ; 

001 0011 * 0100 0011 0001 1000 CntOone: goto[.+l], IncSufAdr; 

001 0100 1 = 0101 0011 0001 1000 goto[.+l], IncBufAdr; 
001 0101 1 * 0101 0011 0001 0000 goto[.]; 

010 0000 x * 0001 0011 0001 0000 Read/VerifyHeader: goto[.+l]; 

010 0001 1 * 0010 1010 0001 0000 Cnt «• 1110, goto[.+l]; 

;2-word loop transfers data to device holding register 

010 0010 1 * 0010 0011 0101 0000 Waitloop: goto[.+l,., XferOataS]; 

010 0010 * 0011 0111 1001 1100 IncCtr, IncBufAdr, Dev «- Buf, 

goto[CntDone,CntWait,CntCry]; 

010 0011 1 * 0010 0011 0001 0000 CntWait: goto[WaitLoop] ; 

010 0011 = 0100 1010 0001 0000 CntOone: goto[.+l], Cnt «• 1110; 

;2-word loop transfers data from device holding register to buffer 

010 0100 1 » 0100 0011 0101 0000 WaitLoopA: goto[.+l, .•, XferOataS]; 
010 0100 * 0101 0111 1001 1010 IncCtr, IncBufAdr, WrtBuf, 
goto[CntOoneA , CntWai tA , CntCry ] ; 

010 0101 1 * 0100 0011 0001 0000 CntWaitA:goto[WaitLoopA]; 
010 0101 * 0110 0011 0001 0000 CntOoneA: goto[.+l]; 

;Wait for one more XferOataS, and generate a wakeup 

010 0110 1 - 0110 0011 0101 0000 goto[.+l. . .XferOataS]; 
010 0110 * 0111 0011 0001 0000 goto[.+l]; 

010 0111 1 « 1000 0011 0011 0000 OataWake. goto[.*l]; 

010 1000 1 * 1000 0011 0001 0000 goto[.]; 



Data Bits Are: 

0-3: BufNxtAdr[3:6] 

4-7: dBrC.2, dlnC, dCIC', dldC 

8-11: dBrC, dBrX, dDtW, dCl rMemBuf Adr' 

12-15: dlncDevBufAdr, dDev«-Buf, dWrtBuf, dREP 

Address; Data: 

Oil 0000 x * 0001 0011 0001 0000 WriteLabel: goto[.+l]; 

Oil 0001 1 * 0010 0010 0001 0000 Cnt «- 1100, goto[.+l]; 

;4-word loop to transfer the first four label words to the device holding register from the 

buffer 

011 0010 1 * 0010 0011 0101 0000 WaitLoop: goto[ .+1, . ,Xf erDataS] ; 

011 0010 = 0011 0111 1001 1100 IncCtr, IncBufAdr, Dev <- Buf, goto[CntDone, CntWait, 

CntCry]; 

Oil 0011 1 = 0010 0011 0001 0000 CntWait: goto[WaitLoop] ; 

Oil 0011 = 0100 0010 0001 0000 CntDone: Cnt <- 1100, goto[. + l]; 

;4-word loop to transfer the second four label words to the device holding register from the 

buffer 

011 0100 1 = 0100 0011 0101 0000 WaitLoopA: goto[ .+1, . .XferDataS]; 

011 0100 = 0101 0111 1001 1100 IncCtr, IncBufAdr, Dev <- Buf, goto[CntDoneA, CntWaitA, 

CntCry]; 

011 0101 1 = 0100 0011 0001 0000 CntWaitA: goto[WaitLoopA] ; 

011 0101 * 0110 0010 0001 0000 CntDoneA: Cnt <- 1100, goto[.+l]; 

;4 cycles are spent incrementing the device buffer address 

011 0110 1 = 0110 0111 1001 1000 IncCtr, IncBufAdr, goto[.+l, ., CntCry] ; 

011 0110 * 0111 0011 0001 0000 goto[.+l]; 

Oil 0111 1 = 0111 0011 0001 0000 goto[.+l]; 



Oata 81ts Are: 

0-3: BufNxtAdr(3:6] 

4-7: dBrC.2, dlnC, dClC\ dLdC 

8-11: dBrC, dBrX, dDtW, dCl rMemfluf Adr' 

12-15: dlncOevBufAdr, dDev«-Buf, dWrtBuf, dREP 

Address: Oata: 

100 0000 x * 0001 0011 0001 0000 Read/Verifytabel: goto[.+l]; 

100 0001 1 * 0010 1010 0001 0000 Cnt «• 1110, goto[.+l]; 

;2-word loop transfers the first two words from the buffer to the device holding register. 

100 0010 1 = 0010 0011 0101 0000 WaitLoop: goto[ .+1, . .XferOataS] ; 

100 0010 « 0011 0111 1001 1100 IncCtr, IncBufAdr, Dev <- Buf . goto[CntDone, CntWait. 

CntCry]; 

100 0011 1 * 0010 0011 0001 0000 CntWait: goto[WaitLoop]; 

100 0011 * 0100 0010 0001 0000 CntOone: Cnt «• 1100, goto[.+l]; 

;4-word loop sends a word to the device holding register, then reads a word from 

;the device holding register into the buffer. 

100 0100 1 » 0100 0011 0101 0000 WaitLoopA: goto[ .+1, . ,Xf erOataS] ; 

100 0100 = 0101 0111 1001 0100 IncCtr, Dev «• Buf, goto[CntOoneA, CntWaitA, CntCry]; 

100 0101 1 » 0100 0011 0001 1010 CntWaitA: IncBufAdr, WrtBuf, goto[WaitLoopA] ; 

100 0101 * 0110 1010 0001 1010 CntOoneA: Cnt - 1110, IncBufAdr, WrtBuf, goto[.+l]; 

;2-word loop sends a word to the device holding register, then reads a word from 

;the device holding register into the buffer. 

100 0110 1 * 0110 0011 0101 0000 WaitLoopB: goto[.+l, . .XferOataS]; 

100 0110 * 0111 0111 1001 0100 IncCtr, Dev «- Buf, goto[CntDone8, CntWaitB, CntCry]; 

100 0111 1 » 0110 0011 0001 1010 CntWaitB: IncBufAdr, Wrt8uf. goto(WaitLoopB] ; 
100 0111 * 1000 0011 0001 1010 CntOoneB: IncBufAdr, WrtBuf, goto[.+l]; 

100 1000 1 * 1001 0011 0001 0000 goto[.+l]; 

* Cause s wakeuD 

100 1001 1 * 1010 1010 0011 0000 Cnt <- 1110, OataWake, goto[.+l]; 

;2-word loop transfers the final two words from the device holding register to the buffer. 

100 1010 1 * 1010 0011 0101 0000 WaitLoopC: goto[ :+l, . ,Xf erOataS] ; 

100 1010 * 1011 0111 1001 1010 IncCtr, IncBufAdr, WrtBuf, goto[CntDoneC, CntWaitC- 

CntCry]; 

100 1011 1 » 1010 0011 0001 0000 CntWaitC: goto[WaitLoopC] ; 
100 1011 = 1100 0011 0001 0000 CntOoneC: goto[.+l]; 

;Wait for one more XferDataS, cause a wakeup, and increment the buffer address by 2. 

100 1100 1 = 1100 0011 0101 0000 goto[.+l,. .XferDataS]; 

100 1100 * 1101 0011 0011 1000 DataWake, IncBufAdr, goto[.+l]; 

100 1101 1 = 1110 0011 0001 1000 IncBufAdr, goto[.+l]; 

100 1110 1 * 1110 0011 0001 0000 goto[.]; 



Data Bits Are: 

0-3: BufNxtAdr[3:6] 

4-7: dBrC.2, dlnC, dCIC', dldC 

8-11: dBrC, dBrX, dDtW, dCl rMemBuf Adr' 

12-15: dlncDevBufAdr, dDev*-Buf, dWrtBuf, dREP 

Address: Data: 

101 0000 x = 0001 0011 0001 0000 WriteData: goto[.+l]; 

101 0001 1 = 0010 0011 0001 0000 goto[.+l]; 

;Send one word to the device holding register 

101 0010 1 = 0010 0011 0101 0000 WaitLoop: goto[ .+1, . .XferDataS] ; 

101 0010 = 0011 0011 0001 1100 IncBufAdr, Dev <- Buf, goto[.+l]; 

;Wakeup, set up count 

101 0011 1 = 0100 0001 0011 0000 Cnt - 0000, DataWake, goto[.+l]; 

;Send 16 words with REP equal zero, 

101 0100 1 = 0100 0011 0101 0000 FirstLoop: goto[ .+1 ,., XferDataS] ; 

101 0100 = 0101 0111 1001 1100 IncCtr, IncBufAdr, Dev *- Buf , goto[CntDone, CntWait, 

CntCry]; 

101 0101 1 = 0100 0011 0001 0000 CntWait: goto[FirstLoop]; 
101 0101 = 0110 0011 0001 0000 CntDone: goto[MainSetup] ; 

;Cause a wakeup, send 16words (forever) REP equals 1. 

101 0110 1 = 0111 0001 0011 0001 MainSetup: Cnt <- 0000, DataWake, REP, goto[.+l]; 

101 0111 1 = 0111 0011 0101 0001 MainLoop: goto[ .+1, ., XferDataS] ; 

101 0111 = 1000 0111 1001 1101 IncCtr, IncBufAdr, Dev <- Buf, REP, goto[CntDoneA, 

CntWaitA, CntCry]; 

101 1000 1 = 0111 0011 0001 0001 CntWaitA: REP, goto[MainLoop]; 
101 1000 = 0110 0011 0001 0001 CntDoneA: REP, goto[MainSetup] ; 



Oata Bits Are: 

0-3: BufNxtAdr[3:6] 

4-7: dBrC.2, dlnC, dClC\ dLdC 

8-11: dBrC, dBrX, dOtW, dCl rMemBufAdr' 

12-15: dlncDevBufAdr, dDev«-8uf , dWrtBuf, dREP 



Address: 



Oata: 



110 0000 x * 0001 0011 0001 0000 ReadOata: goto[.+l]; 

;Wait for XferOata and increment the buffer address, but don't write the buffer. 

110 0001 1 * 0001 0011 0101 0000 goto[.+l, . ,XferOataS]; 

110 0001 = 0010 0010 0001 1000 Cnt - 1100, IncBufAdr, goto[.+l]; 

;4-word loop transfers data from the device holding register to the buffer - no wakeups yet. 

110 0010 1 » 0010 0011 0101 0000 WaitLoop: goto[ .+1 , . , XferOataS] ; 

110 0010 = 0011 0111 1001 1010 IncCtr, IncBufAdr, WrtBuf, goto[CntDone, CntWait, 

CntCry]; 

110 0011 1 • 0010 0011 0001 0000 CntWait: goto[WaitLoop] ; 

110 0011 = 0100 0010 0001 0000 CntOone: Cnt «• 1100, goto[.+l]; 

; 4-word loop transfers data from the device holding register to the buffer - no waiceups yet. 

110 0100 1 = 0100 0011 0101 0000 WaitLoopA: goto[ . + 1 ... XferOataS] ; 

110 0100 * 0101 0111 1001 1010 IncCtr, IncBufAdr, WrtBuf, goto[CntOoneA, CntWaitA, 

CntCry]; 

110 0101 1 * 0100 0011 0001 0000 CntWaitA: goto[WaitLoopA]; 

110 0101 * 0110 0010 0001 0000 CntDoneA: Cnt «• 1100. goto[.+l]; 

; 4-word loop transfers data from the device holding register to the buffer - no waiceups yet. 

110 0110 1 * 0110 0011 0101 0000 WaitLoopB: goto[ .+1 ,. .XferOataS] ; 

110 0110 * 0111 0111 1001 1010 IncCtr, IncBufAdr, WrtBuf, gotoCCntOoneB, CntWaitB, 

CntCry]; 

110 0111 1 * 0110 0011 0001 0000 CntWaitB: goto[WaitLoop8]; 

110 0111 » 1000 0010 0001 0000 CntDoneB: Cnt «■ 1100, goto[.+l]; 

; 4-word loop transfers data from the device holding register to the buffer - no wakeups yet. 

110 1000 1 * 1000 0011 0101 0000 WaitLoopC: goto[ . +1 .. .XferOataS] : 

110 1000 * 1001 0111 1001 1010 IncCtr, IncBufAdr, WrtBuf, goto[CntOoneC, CntWaitC, 

CntCry]; 

110 1001 1 * 1000 0011 0001 0000 CntWaitC: goto[WaitloopC] ; 

110 1001 » 1010 0011 0001 0000 CntOoneC: goto[.+l]; 



-.transfer one more word... 

110 1010 1 = 1010 0011 0101 0000 
110 1010 = 1011 0011 0001 1010 



goto[.fl, . .XferOataS]; 
IncBufAdr, WrtBuf, goto[.*l]; 



;cause a walceup and set up for 16 word loop 

110 1011 1 = 1100 0001 0011 0000 Cnt - 0000, OataWake, goto[.+l]; 

; 16-word loop writes words to the buffer, then causes a wakeup (forever). 

110 1100 1 * 1100 0011 0101 0000 MainLoop: goto[ . +1 ,. .XferOataS] ; 

110 1100 = 1101 0111 1001 1010 IncCtr. IncBufAdr, WrtBuf, goto[CntOoneO, CntWaitD. 

CntCry]; 



110 1101 1 

110 1101 



1100 0011 0001 0000 CntWaitO: 
1100 0001 0011 000C CntDoneD: 



goto[MainLoop] ; 
Cnt *• 0000, OataWake. goto[MainLoop] : 



Data Bits Are: 

0-3: BufNxtAdr[3:6] 

4-7: dBrC.2, dlnC, dClC , dLdC 

8-11: dBrC, dBrX, dDtW, dCl rMemBuf Adr ' 

12-15: dlncDevBufAdr, dDev«-Buf, dWrtBuf, dREP 

Address: Data: 

111 0000 x = 0001 0011 0001 0000 VerifyOata: goto[.+l]; 

111 0001 1 = 0010 0011 0001 0000 goto[.+l]; 

;Send one word to the device holding register. 

Ill 0010 1 = 0010 0011 0101 0000 WaitLoop: goto[ .+1, . .XferDataS] ; 

111 0010 = 0011 0011 0001 1100 IncBufAdr, Dev «■ Buf, goto[.+l]; 

:Cause a wakeup, set up for 16-word loop. 

Ill 0011 1 = 0100 0001 0011 0000 Cnt «- 0000, DataWake, goto[.+l]; 

: 16-word loop . . . 

Ill 0100 1 = 0100 0011 0101 0000 WaitLoopA: goto[ .+1 , . ,Xf erDataS] ; 

111 0100 = 0101 0111 1001 1100 IncCtr, IncBufAdr, Dev <- Buf, goto[CntDone, CntWait, 

CntCry]; 

111 0101 1 = 0100 0011 0001 0000 CntWait: goto[WaitLoopA]; 
111 0101 = 0110 0011 0001 0000 CntDone: goto[MainLoopSetup] ; 

;Cause a wakeup, set up for 16-word main loop, which transfers forever. 

Ill 0110 1 = 0111 0001 0011 0001 MainLoopSetup: Cnt <- 0000, DataWake, goto[.+l]; 

111 0111 1 = 0111 0011 0101 0001 MainLoop: goto[ .+1, . .XferDataS] ; 

111 0111 = 1000 0111 1001 1101 IncCtr, IncBufAdr, Dev «- Buf, goto[CntDoneA, CntWaitA, 

CntCry]; 

111 1000 1 = 0111 0011 0001 0001 CntWaitA: goto[MainLoop]; 

111 1000 = 0110 0011 0001 0001 CntDoneA: goto[MainLoopSetup]; 



The following listing is for the Format Sequencer. 

The (decimal) location in the memory is given, followed by 

the contents of the memory in the following order: 

ForNxtAdr.0-6 (7 bits) 

dForCnt.0-4 (5 bits) 

dBrOnSync 

dSequenceEnd 

dSectorWake 

dCl rOevOp ' 

dXferTime 

dSyncTime 

dOataTime 

dCRCShift 

dCRCWMte 

dCRCCheck 

dWriteGate 

dReadGate 

dECCClear 

dECCShift 

dECCWrite 

ddECCCheck 

(28 bits total) 



For each location, the control bits (marked with • above) are shown in text form. 
The quantities in parentheses are the address of the instruction that will be executed 
following the current instruction, and (if the current address is even) the number of 
cycles that the sequencer will remain at that location. 

The Basic Sequencer Operation is given at the start of each sequence. 



Seek: 

000: 
001: 
002: 
003: 
004: 
006: 
006: 
007: 
008: 
009: 
010: 
011: 
012: 
013: 
014: 
015: 
016: 



0000000 
0000000 
0000001 
0000010 
0000010 
0000011 
0000011 
0000011 
0000100 
xxxxxxx 
0000101 
xxxxxxx 
0000110 
0000111 
0000111 
1000010 
0001000 



Write Header: 
017: 0001001 
018: 0001001 
019: 0001010 
020: 0001010 
021: 0001011 
022: 0001011 
023: 0001100 
024: 0001100 
025: 0001101 
025: 0001101 
027: 0001110 
028: 0001110 
029: 0001111 
030: 0001111 
031: 0000001 
032: 0010000 

Read Header: 



xxxxx 
xxxxx 
xxxxx 
11111 
xxxxx 
xxxxx 
xxxxx 
xxxxx 
xxxxx 
xxxxx 
xxxxx 
xxxxx 
xxxxx 
00000 
xxxxx 
00000 
xxxxx 



11111 

xxxxx 

10110 
xxxxx 

inn 

xxxxx 

11110 
xxxxx 
11110 
xxxxx 
11110 
xxxxx 
11110 
xxxxx 
11110 
xxxxx 



0001 
0001 
0001 
0101 
xxOl 
0101 
0001 
0001 
xxOl 
xxOl 
xxOl 
xxOl 
0001 
0001 
0001 
0001 
0001 



0001 
xxOl 
0000 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 



0000 
0000 
0000 
0000 
0000 
0000 
0000 
0000 
xxxx 
xxxx 
xxxx 
xxxx 
1010 
1010 
1010 
1010 
0000 



0000 
0000 
0000 
0000 
1000 
1000 
1100 
1100 
1011 
1011 
0011 
0011 
0001 
0001 
0000 
0000 



0000 
0000 
0000 
0000 
0000 
0000 
0000 
0000 
xxxx 
xxxx 
xxxx 
xxxx 
0001 
0001 
0001 
0001 
0000 



0010 
0010 
0010 
0010 
0010 
0010 
0010 
0010 
0010 
0010 
0010 
0010 
1010 
1010 
0010 
0000 



0000 
0000 
0000 
0000 
0000 
0000 
0000 
0000 
xxxx 
xxxx 
xxxx 
xxxx 
0100 
0100 
0100 
0100 
0000 



0000 
0000 
0000 
0000 
0000 
0000 
0000 
0000 
0100 
0100 
0100 
0100 
0000 
0000 
0000 
0000 



033 
034 
035 



0010001 11111 0001 0000 0000 0000 
0010001 xxxxx xxOl 0000 0000 0000 
0010010 11110 0000 0000 0001 0000 



000) 
000) 
002) 
005, 
004) 
006) 
006) 
006) 
008) 
000) 
010) 
000) 
012) 
014, 
014) 
132, 
016) 



000) SeqEnd 
SeqEnd 



XfrTime DataTime ReadGate ECCShift 

031) XfrTime DataTime ReadGate ECCShift 

XfrTime DataTime ReadGate ECCShift 

031) XfrTime OataTime ReadGate ECCShift 



019,000) WriteGate 
018) WriteGate 
020,009) ClrDevOp WriteGate 
020) WriteGate 

023.000) XfrTime WriteGate 
022) XfrTime WriteGate 

024.001) XfrTime SyncTime WriteGate 
024) XfrTime SyncTime WriteGate 

026,001) XfrTime DataTime CRCShift WriteGate ECCShift 
026) XfrTime DataTime CRCShift WriteGate ECCShift 
028,001) DataTime CRCShift WriteGate ECCShift 
028) DataTime CRCShift WriteGate ECCShift 
030,001) CRCShift CRCWrite WriteGate 
030) CRCShift CRCWrite WriteGate 
002,001) WriteGate 
032) 



035,000) 

034) 

036.001) CI rOevOp ReadGate 



8 



036: 
037: 
038: 
039: 
040: 
041: 
042: 
043: 
044: 
045: 
046: 
047: 
048: 



0010010 
0010011 
0010011 
0010100 
0010100 
0010101 
0010101 
0010110 
0010110 
0010111 
0010111 
0000001 
0011000 



xxxxx 
11011 
xxxxx 
11110 
xxxxx 
xxxxx 
xxxxx 
11100 
xxxxx 
11110 
xxxxx 
11110 
xxxxx 



0001 
0001 
0001 
0001 
0001 
1001 
1001 
0001 
0001 
0001 
0001 
0001 
xxOl 



0000 
0000 
0000 
1000 
1000 
0100 
0100 
1011 
1011 
1001 
1001 
0000 



0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0101 



0000 
0000 
0000 
0000 
0000 
0000 
0000 
0100 
0100 
0100 
0100 
0000 



xxxx xxxx xxxx 



Write Label : 

049: 0011001 

050: 0011001 

051: 0011010 

052: 0011010 

053: 0011011 

054: 0011011 

055: 0011100 

056: 0011100 

057: 0011101 

058: 0011101 

059: 0011110 

060: 0011110 

061: 0000001 

062: 0011111 

063: xxxxxxx 

064: 0100000 

Read/Verify 
065: 0100001 
066: 0100001 
067: 0100010 
068: 0100010 
069: 0100011 
070: 0100011 
071: 0100100 
072: 0100100 
073: 0100101 
074: 0100101 
075: 0100110 
076: 0100110 
077: 0000001 
078: 0100111 
079: 1110000 
080: 0101000 



11000 
xxxxx 

11111 

xxxxx 

11110 
xxxxx 
10010 
xxxxx 
11110 
xxxxx 
11110 
xxxxx 
11110 
xxxxx 
xxxxx 
xxxxx 

Label : 
11111 
xxxxx 
11100 
xxxxx 
11110 
xxxxx 
xxxxx 
xxxxx 
10000 
xxxxx 
11110 
xxxxx 
11110 
xxxxx 
00000 
xxxxx 



Write 

081: 
082: 
083: 
084: 
085: 
086: 
087: 
088: 
089: 
090: 
091: 
f!Q2 • 

092. 
094: 
095: 
096: 



Data: 

0101001 
0101001 
0101010 
0101010 
0101011 
0101011 
0101100 
0101100 
0101101 
C 1 1 1 1 
0101110 
0101110 

iu 1 1 1 1 

0101111 
1100010 
0110000 



11000 
xxxxx 

11111 

xxxxx 

11110 
xxxxx 
00000 
xxxxx 
00000 
xxxxx 
00000 
xxxxx 
00000 
xxxxx 
00000 
xxxxx 



0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
xxOl 
xxOl 
xxOl 



0001 
xxOl 
0001 
0001 
0001 
0001 
1001 
1001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
xxOl 



0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
xxOl 



0000 
0000 
1000 
1000 
1100 
1100 
1011 
1011 
0011 
0011 
0001 
0001 
0000 
xxxx 
xxxx 
xxxx 



0000 
xxxx 

0000 
0000 
1000 
1000 
0100 
0100 
1011 
1011 
1001 
1001 
0000 
1010 
1010 
xxxx 



0000 
0000 
1000 
1000 
1100 
1100 
1010 
1010 
1010 
1010 
1010 
1010 
1010 
1010 
1010 
xxxx 



0010 
0010 
0010 
0010 
0010 
0010 
0010 
0010 
0010 
0010 
1010 
1010 
0010 
xxxx 
xxxx 
xxxx 



0000 
xxxx 

0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0101 
0001 
0001 
xxxx 



0010 
0010 
0010 
0010 
0010 
0010 
0010 
0010 
0010 
0010 
0010 
0010 
0010 
0010 
0010 
xxxx 



0000 
0000 
0000 
0000 
0000 
0000 
0100 
0100 
0100 
0100 
0000 
0000 
0000 
xxxx 
xxxx 
xxxx 



0000 
xxxx 

0000 
0000 
0000 
0000 
0000 
0000 
0100 
0100 
0100 
0100 
0000 
0100 
0100 
xxxx 



1100 
1100 
0000 
0000 
0000 
0000 
0100 
0100 
0100 
0100 
0100 
0100 
0100 
0100 
0100 
xxxx 



Read Data: 



097 
098 
099 



0110001 11111 0001 0000 0000 0000 
0110001 xxxxx xxOl xxxx xxxx xxxx 

0110010 11010 0001 0000 0001 1100 



036) 

038,004) 

038) 

040,001) 

040) 

042) 

042) 

044,003) 

044) 

046,001) 

046) 

002,001) 

048) 



050,007) 

050) 

053,000) 

052) 

054,001) 

054) 

056,013) 

056) 

058,001) 

058) 

060,001) 

060) 

002,001) 

062) 

000) 

064) 



ReadGate 

ReadGate 

ReadGate 

XfrTime ReadGate 

XfrTime ReadGate 

BrSync SyncTime ReadGate 

BrSync SyncTime ReadGate 

XfrTime DataTime CRCShift ReadGate ECCShift 

XfrTime DataTime CRCShift ReadGate ECCShift 

XfrTime CRCShift ReadGate ECCShift 

XfrTime CRCShift ReadGate ECCShift 

CRCCheck ReadGate 



WriteGate 

WriteGate 

XfrTime WriteGate 

XfrTime WriteGate 

XfrTime SyncTime WriteGate 

XfrTime SyncTime WriteGate 

XfrTime DataTime CRCShift WriteGate ECCShift 

XfrTime DataTime CRCShift WriteGate ECCShift 

DataTime CRCShift WriteGate ECCShift 

DataTime CRCShift WriteGate ECCShift 

CRCShift CRCWrite WriteGate 

CRCShift CRCWrite WriteGate 

WriteGate 



067,000) 

066) 

068,003) 

068) 

070,001) 

070) 

072) 

072) 

074,015) 

074) 

076,001) 

076) 

002,001) 

078) 

224,031) 

080) 



082,007) 

082) 

085,000) 

084) 

086.001) 

086) 

088,031) 

088) 

090,031) 

090) 

092,031) 

092) 

094,031) 

094) 

196,031) 

096) 



ReadGate 

ReadGate 

XfrTime ReadGate 

XfrTime ReadGate 

BrSync SyncTime ReadGate 

BrSync SyncTime ReadGate 

XfrTime DataTime CRCShift ReadGate ECCShift 

XfrTime DataTime CRCShift ReadGate ECCShift 

XfrTime CRCShift ReadGate ECCShift 

XfrTime CRCShift ReadGate ECCShift ' 

CRCCheck ReadGate 

XfrTime DataTime ReadGate ECCShift 

XfrTime DataTime ReadGate ECCShift 



WriteGate ECClr ECCShift 
WriteGate ECClr ECCShift 
XfrTime WriteGate 
XfrTime WriteGate 
XfrTime SyncTime WriteGate 
XfrTime SyncTime WriteGate 
XfrTime DataTime WriteGate ECCShift 
XfrTime DataTime WriteGate ECCShift 
XfrTime DataTime WriteGate ECCShift 
XfrTime DataTime WriteGate ECCShift 
XfrTime DataTime WriteGate ECCShift 
XfrTime DataTime WriteGate ECCShift 
XfrTime DataTime WriteGate ECCSrifi 
XfrTime DataTime WriteGate ECCShift 
XfrTime DataTime WriteGate ECCShift 



099,000) 

098) 

100,005) ReadGate ECClr ECCShift 



100: 


0110010 


xxxxx 


0001 


0000 


0001 


1100 


(100) 


ReadGate ECCIr ECCShift 




101: 


0110011 


xxxxx 


1001 


0100 


0001 


0000 


(102) 


BrSync SyncTime ReadGate 




102: 


0110011 


xxxxx 


1001 


0100 


0001 


0000 


(102) 


BrSync SyncTime ReadGate 




103: 


0110100 


11111 


0001 


0010 


0001 


0100 


(106,000) 


DataTime ReadGate ECCShift 




104: 


0110100 


xxxxx 


0001 


0010 


0001 


0100 


(104) 


DataTime ReadGate ECCShift 




105: 


0110101 


00001 


0001 


1010 


0001 


0100 


(106,030] 


XfrTime OataTime 


ReadGate 


ECCShift 


106: 


0110101 


xxxxx 


0001 


1010 


0001 


0100 


(106) 


XfrTime OataTime 


ReadGate 


ECCShift 


107: 


0110110 


00000 


0001 


1010 


0001 


0100 


(108, 03V 


) XfrTime DataTime 


ReadGate 


ECCShift 


108: 


0110110 


xxxxx 


0001 


1010 


0001 


0100 


(108) 


XfrTime DataTime 


ReadGate 


ECCShift 


109: 


0110111 


00000 


0001 


1010 


0001 


0100 


(110,031 


) XfrTime DataTime 


ReadGate 


ECCShift 


110: 


0110111 


xxxxx 


0001 


1010 


0001 


0100 


(110) 


XfrTime DataTime 


ReadGate 


ECCShift 


111. 


0000110 


00000 


0001 


1010 


0001 


0100 


(012,031 


) XfrTime DataTime 


ReadGate 


ECCShift 


112. 


0111000 


xxxxx 


xxOl 


xxxx 


xxxx 


xxxx 


(112) - 








Verify Data: 




















113 


0111001 


11111 


0001 


0000 


0000 


0000 


(115,000 








114 


0111001 


xxxxx 


xxOl 


xxxx 


xxxx 


xxxx 


(114) 








115 


0111010 


11100 


0001 


0000 


0001 


1100 


(116, 003 1 


) ReadGate ECC1 r ECCShift 




116 


0111010 


xxxxx 


0001 


0000 


0001 


1100 


(116) 


ReadGate ECC1 r ECCShift 




117 


0111011 


11110 


0001 


1000 


0001 


0000 


(118,001 


) XfrTime ReadGate 






118 


0111011 


xxxxx 


0001 


1000 


0001 


0000 


(118) 


XfrTime ReadGate 






119 


0111100 


xxxxx 


1001 


0100 


0001 


0000 


(120) 


BrSync SyncTime ReadGate 




120 


0111100 


xxxxx 


1001 


0100 


0001 


0000 


(120) 


BrSync SyncTime ReadGate 




121 


0111101 


00000 


0001 


1010 


0001 


0100 


(122.031 


) XfrTime DataTime 


ReadGate 


ECCShift 


122 


0111101 


xxxxx 


0001 


1010 


0001 


0100 


(122) 


XfrTime DataTime 


ReadGate 


ECCShift 


123 


0111110 


00000 


0001 


1010 


0001 


0100 


(124,031 


) XfrTime DataTime 


ReadGate 


ECCShift 


124 


0111110 


xxxxx 


0001 


1010 


0001 


0100 


(124) 


XfrTime DataTime 


ReadGate 


ECCShift 


125 


0111111 


00000 


0001 


1010 


0001 


0100 


(126,031 


) XfrTime DataTime 


ReadGate 


ECCShift 


126 


0111111 


xxxxx 


0001 


1010 


0001 


0100 


(126) 


XfrTime DataTime 


ReadGate 


ECCShift 


127 


0100111 


00000 


0001 


1010 


0001 


0100 


(078,031 


) XfrTime DataTime 


ReadGate 


ECCShift 


128 


1000000 


xxxxx 


0001 


0000 


0000 


0000 


(128) 








Nop 


Header: 




















129 


1000001 


01100 


0001 


0000 


0000 


0000 


(130,019 








130 


1000001 


xxxxx 


0001 


0000 


0000 


0000 


(130) 








131 


0000001 


11110 


0000 


0000 


0000 


0000 


(002.001 


) ClrDevOp 






132 


1000010 


xxxxx 


0001 


1010 


0001 


0100 


(132) 


XfrTime DataTime 


ReadGate 


ECCShift 


133 


1000011 


00000 


0001 


1010 


0001 


0100 


(134,031 


) XfrTime DataTime 


ReadGate 


ECCShift 


134 


1000011 


xxxxx 


0001 


1010 


0001 


0100 


(134) 


XfrTime DataTime 


ReadGate 


ECCShift 


135 


1000100 


00000 


0001 


1010 


0001 


0100 


(136,031 


) XfrTime DataTime 


ReadGate 


ECCShift 


136 


1000100 


xxxxx 


0001 


1010 


0001 


0100 


(136) 


XfrTime DataTime 


ReadGate 


ECCShift 


137 


1000101 


00000 


0001 


1010 


0001 


0100 


(138,031 


) XfrTime DataTime 


ReadGate 


ECCShift 


138 


1000101 


xxxxx 


0001 


1010 


0001 


0100 


(138) 


XfrTime DataTime 


ReadGate 


ECCShift 


139 


1000110 


00000 


0001 


1010 


0001 


0100 


(140.031 


) XfrTime DataTime 


ReadGate 


ECCShift 


140 


1000110 


xxxxx 


0001 


1010 


0001 


0100 


(140) 


XfrTime DataTime 


ReadGate 


ECCShift '- 


141 


1000111 


00000 


0001 


1010 


0001 


0100 


(142,031 


) XfrTime DataTime 


ReadGate 


ECCShift 


142 


1000111 


xxxxx 


0001 


1010 


0001 


0100 


(142) 


XfrTime DataTime 


ReadGate 


ECCShift 


143 


1001001 


00000 


0001 


1010 


0001 


0100 


(146.031 


) XfrTime DataTime 


ReadGate 


ECCShift 


144 


1001000 


xxxxx 


xxOl 


xxxx 


xxxx 


xxxx 


(144) 








Nop 


Label : 




















145 


0000001 


00001 


0001 


0000 


0000 


0000 


(002,030 








146 


1001001 


xxxxx 


0001 


1010 


0001 


0100 


(146) 


XfrTime DataTime 


ReadGate 


ECCShift 


147 


1001010 


00000 


0001 


1010 


0001 


0100 


(148.031 


) XfrTime DataTime 


ReadGate 


ECCShift • 


148 


1001010 


xxxxx 


0001 


1010 


0001 


0100 


(148) 


XfrTime DataTime 


ReadGate 


ECCShift 


149 


1001011 


00000 


0001 


1010 


0001 


0100 


(150,031 


) XfrTime DataTime 


ReadGate 


ECCShift 


150 


1001011 


xxxxx 


0001 


1010 


0001 


0100 


(150) 


XfrTime DataTime 


ReadGate 


ECCShift 


151 


1001100 


00000 


0001 


1010 


0001 


0100 


(152,031 


) XfrTime DataTime 


ReadGate 


ECCShift 


152 


• 1001100 


xxxxx 


0001 


1010 


0001 


0100 


(152) 


XfrTime DataTime 


ReadGate 


ECCShift 


153 


1001101 


00000 


0001 


1010 


0001 


0100 


(154,031 


) XfrTime DataTime 


ReadGate 


ECCShift 


154 


1001101 


xxxxx 


0001 


1010 


0001 


0100 


(154) 


XfrTime DataTime 


ReadGate 


ECCShift 


155 


1001110 


11100 


0001 


1000 


0001 


0100 


(156,003 


) XfrTime ReadGate 


ECCShift 




156 


• 1001110 


xxxxx 


0001 


1000 


0001 


0100 


(156) 


XfrTime ReadGate 


ECCShift 




157 


1001111 


11100 


0001 


1000 


0001 


1111 


(158,003 


) XfrTime ReadGate 


ECClr ECCShift ECCWrite 


£CC( 


:hk 




















153 


• 1001111 


xxxxx 


0001 


1000 


0000 


1111 


(158) 


XfrTime ECC1 r ECCShift ECCWrite ECCChk 


159 


: 0000010 


11111 


0111 


0000 


0000 


0000 


(005,000 


) SeqEnd SectWk 






160 


: 1010000 


xxxxx 


xxOl 


xxxx 


xxxx 


xxxx 


(160) 








Nop 


Data: 




















161 


: 1010001 


00000 


0001 


0000 


0000 


0000 


(162,031 








162 


: 1010001 


xxxxx 


0001 


0000 


0000 


0000 


(162) 









10 



163 


1010010 


00000 


0001 


0000 


0000 


0000 


(164,031) 










164 


1010010 


xxxxx 


0001 


0000 


0000 


0000 


(164) 










165 


1010011 


00000 


0001 


0000 


0000 


0000 


(166,031) 










166 


1010011 


xxxxx 


0001 


0000 


0000 


0000 


(166) 










167 


1010100 


00000 


0001 


0000 


0000 


0000 


(168,031) 










168 


1010100 


xxxxx 


0001 


0000 


0000 


0000 


(168) 










169 


1010101 


00000 


0001 


0000 


0000 


0000 


(170,031) 










170 


1010101 


xxxxx 


0001 


0000 


0000 


0000 


(170) 










171 


1010110 


00000 


0001 


0000 


0000 


0000 


(172,031) 










172 


1010110 


xxxxx 


0001 


0000 


0000 


0000 


(172) 










173 


1010111 


00000 


0001 


0000 


0000 


0000 


(174,031) 










174 


1010111 


xxxxx 


0001 


0000 


0000 


0000 


(174) 










175 


1011001 


00000 


0001 


0000 


0000 


0000 


(178,031) 










176 


1011000 


xxxxx 


0001 


0000 


0000 


0000 


(176) 










177 


1011000 


xxxxx 


0001 


0000 


0000 


0000 


(176) 










178 


1011001 


xxxxx 


0001 


0000 


0000 


0000 


(178) 










179 


1011010 


00000 


0001 


0000 


0000 


0000 


(180,031) 










180 


1011010 


xxxxx 


0001 


0000 


0000 


0000 


(180) 










181 


1011011 


00000 


0001 


0000 


0000 


0000 


(182,031) 










182 


1011011 


xxxxx 


0001 


0000 


0000 


0000 


(182) 










183 


1011100 


00000 


0001 


0000 


0000 


0000 


(184,031) 










184 


1011100 


xxxxx 


0001 


0000 


0000 


0000 


(184) 










185 


1011101 


00000 


0001 


0000 


0000 


0000 


(186,031) 










186 


1011101 


xxxxx 


0001 


0000 


0000 


0000 


(186) 










187 


1011110 


00000 


0001 


0000 


0000 


0000 


(188,031) 










188 


1011110 


xxxxx 


0001 


0000 


0000 


0000 


(188) 










189 


1011111 


01111 


0001 


0000 


0000 


0000 


(190,016) 










190 


1011111 


xxxxx 


0001 


0000 


0000 


0000 


(190) 










191 


1100000 


01111 


0001 


0000 


0000 


0000 


(192,016) 










192 


1100000 


xxxxx 


0001 


0000 


0000 


0000 


(192) 










193 


1100001 


00000 


0001 


0000 


0000 


0000 


(194,031) 










194 


1100001 


xxxxx 


0001 


0000 


0000 


0000 


(194) 










195 


0000001 


10001 


0011 


0000 


0000 


0000 


(002,014) 


SectWk 








196 


1100010 


xxxxx 


0001 


1010 


0010 


0100 


(196) 


XfrTime 


DataTime 


WriteGate 


ECCShift 


197 


1100011 


00000 


0001 


1010 


0010 


0100 


(198,031) 


Xf rTime 


DataTime 


WriteGate 


ECCShift 


198 


1100011 


xxxxx 


0001 


1010 


0010 


0100 


(198) 


XfrTime 


DataTime 


WriteGate 


ECCShift 


199 


1100100 


00000 


0001 


1010 


0010 


0100 


(200,031) 


XfrTime 


DataTime 


WriteGate 


ECCShift 


200 


1100100 


xxxxx 


0001 


1010 


0010 


0100 


(200) 


XfrTime 


DataTime 


WriteGate 


ECCShift 


201 


1100101 


00000 


0001 


1010 


0010 


0100 


(202,031) 


XfrTime 


DataTime 


WriteGate 


ECCShift 


202 


1100101 


xxxxx 


0001 


1010 


0010 


0100 


(202) 


XfrTime 


DataTime 


WriteGate 


ECCShift 


203 


1100110 


00000 


0001 


1010 


0010 


0100 


(204,031) 


XfrTime 


DataTime 


WriteGate 


ECCShift 


204 


1100110 


xxxxx 


0001 


1010 


0010 


0100 


(204) 


XfrTime 


DataTime 


WriteGate 


ECCShift 


205 


1100111 


00000 


0001 


1010 


0010 


0100 


(206,031) 


XfrTime 


DataTime 


WriteGate 


ECCShift 


206 


1100111 


xxxxx 


0001 


1010 


0010 


0100 


(206) 


XfrTime 


DataTime 


WriteGate 


ECCShift 


207 


1101000 


00000 


0001 


1010 


0010 


0100 


(208,031) 


XfrTime 


DataTime 


WriteGate 


ECCShift 


208 


1101000 


xxxxx 


0001 


1010 


0010 


0100 


(208) 


XfrTime 


DataTime 


WriteGate 


ECCShift 


209 


1101001 


00000 


0001 


1010 


0010 


0100 


(210,031) 


XfrTime 


DataTime 


WriteGate 


ECCShift 


210 


1101001 


xxxxx 


0001 


1010 


0010 


0100 


(210) 


XfrTime 


DataTime 


WriteGate 


ECCShift 


211 


1101010 


00000 


0001 


1010 


0010 


0100 


(212,031) 


XfrTime 


DataTime 


WriteGate 


ECCShift 


212 


1101010 


xxxxx 


0001 


1010 


0010 


0100 


(212) 


XfrTime 


DataTime 


WriteGate 


ECCShift 


213 


1101011 


00000 


0001 


1010 


0010 


0100 


(214,031) 


XfrTime 


DataTime 


WriteGate 


ECCShift 


214 


1101011 


xxxxx 


0001 


1010 


0010 


0100 


(214) 


XfrTime 


DataTime 


WriteGate 


ECCShift 


215 


1101100 


00000 


0001 


1010 


0010 


0100 


(216,031) 


XfrTime 


DataTime 


WriteGate 


ECCShift 


216 


1101100 


xxxxx 


0001 


1010 


0010 


0100 


(216) 


XfrTime 


DataTime 


WriteGate 


ECCShift 


217 


1101101 


00010 


0001 


1010 


0010 


0100 


(218,029) 


XfrTime 


DataTime 


WriteGate 


ECCShift 


218 


1101101 


xxxxx 


0001 


1010 


0010 


0100 


(218) 


XfrTime 


DataTime 


WriteGate 


ECCShift 


219 


1101110 


11110 


0001 


0010 


0010 


0100 


(220.001) 


DataTime WriteGate ECCShift 


220 


1101110 


xxxxx 


0001 


001C 


0010 


0100 


(220) 


DataTime WriteGate ECCShift 


221 


i 101111 


11100 


0001 


0000 


0010 


1110 


(222,003) 


WriteGate ECClr 


ECCShift ECCWrite 


222 


1101 1 1 1 


xxxxx 


0001 


0000 


0010 


1110 


(222) 


WriteGate ECClr 


: CCShift ECCWrite 


£23 


C OuwO 10 


11111 


0101 


0000 


0010 


0000 


(005.000; 


Seqtnd WriteGate 






224 


1110000 


xxxxx 


0001 


1010 


0001 


0100 


(224) 


XfrTime 


DataTime 


ReadGate 


ECCShift 


225 


• 1110001 


00000 


0001 


1010 


0001 


0100 


(226,031) 


XfrTime 


DataTime 


ReadGate 


ECCShift 


226 


• 1110001 


xxxxx 


0001 


1010 


0001 


0100 


(226) 


XfrTime 


DataTime 


ReadGate 


ECCShift 


227 


. 1110010 


00000 


0001 


1010 


0001 


0100 


(228,031) 


XfrTime 


DataTime 


ReadGate 


ECCShift 


228 


: 1110010 


xxxxx 


0001 


1010 


0001 


0100 


(228) 


XfrTime 


DataTime 


ReadGate 


ECCShift 


229 


: 1110011 


00000 


0001 


1010 


0001 


0100 


(230,031) 


XfrTime 


DataTime 


ReadGate 1 


ECCShift 


230 


: 1110011 


xxxxx 


0001 


1010 


0001 


0100 


(230) 


XfrTime 


DataTime 


ReadGate 


ECCShift 



11 



231: 1110100 

232: 1110100 

233: 1110101 

234: 1110101 

235: 1110110 

236: 1110110 

237: 1110111 

238: 1110111 

239: 1111001 

240: 1111000 

Recovery Gap: 

241: 1111000 

242: 1111001 

243: 1111010 

244: 1111010 

245: 1111011 

246: 1111011 

247: 1111100 

248: 1111100 

249: 1111101 

250: 1111101 

251: 1111110 

252: 1111110 

253: 1111111 

254: 1111111 

255: 0000010 



00000 
xxxxx 
00000 
xxxxx 
00000 
xxxxx 
00000 
xxxxx 
00000 
xxxxx 



xxxxx 
xxxxx 

00000 
xxxxx 
00000 
xxxxx 
00010 
xxxxx 
11110 
xxxxx 
11100 
xxxxx 
11100 
xxxxx 

11111 



0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 



0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0101 



1010 
1010 
1010 
1010 
1010 
1010 
1010 
1010 
1010 
0000 



0000 
1010 
1010 
1010 
1010 
1010 
1010 
1010 
0010 
0010 
0000 
0000 
0000 
0000 
00Q0 



0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0000 



0000 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0001 
0000 
0000 



0100 
0100 
0100 
0100 
0100 
0100 
0100 
0100 
0100 
0000 



(232.031) 

(232) 

(234,031) 

(234) 

(236,031) 

(236) 

(238,031) 

(238) 

(242,031) 

(240) 



0000 
0100 
0100 
0100 
0100 
0100 
0100 
0100 
0100 
0100 
0100 
0100 

1111 
1111 

0000 



Xf pTime 
Xf rTime 
XfrTime 
Xf rTime 
XfrTime 
XfrTime 
XfrTime 
XfrTime 
XfrTime 



OataTime 
OataTime 
OataTime 
OataTime 
OataTime 
OataTime 
OataTime 
OataTime 
OataTime 



ReadGate 
ReadGate 
ReadGate 
ReadGate 
ReadGate 
ReadGate 
ReadGate 
ReadGate 
ReadGate 



ECCShift 
ECCShift 
ECCShift 
ECCShift 
ECCShift 
ECCShift 
ECCShift 
ECCShift 
ECCShift 



(240) 

(242) 

(244,031) 

(244) 

(246,031) 

(246) 

(248,029) 

(248) 

(250,001) 

(250) 

(252,003) 

(252) 

(254,003) 

(254) 

(005.000) 



XfrTime OataTime ReadGate ECCShift 
XfrTime OataTime ReadGate ECCShift 
XfrTime OataTime ReadGate ECCShift 
XfrTime OataTime ReadGate ECCShift 
XfrTime OataTime ReadGate ECCShift 
XfrTime OataTime ReadGate ECCShift 
XfrTime OataTime ReadGate ECCShift 
DataTime ReadGate ECCShift 
OataTime ReadGate ECCShift 
ReadGate ECCShift 
ReadGate ECCShift 

ReadGate ECC1 r ECCShift ECCWrite ECCChk 
ECClr ECCShift ECCWrite ECCChk 
SeqEnd 



